I am using text-transform: lowercase; code to lowercase my users posts. But when i use this code characters like: "i,ş,ç,ü,ğ" are become something else. How can i fix this?
The declaration text-transform: lowercase leaves lowercase letters intact. It is very unlikely that any browser has a problem with this. If you remove the CSS declaration, you will most probably see the letters already as “something else”.
The odds are that the problem is elsewhere, in the transfer of user input to web page content. It is easy to go wrong here, due to character encoding problems. More information about the situation (a URL would be good start, and so would a description of “something else”) is needed to analyze them, and the issue would fall under a different heading.
Regarding lowercasing, it should normally be performed server-side, not in CSS. Note that the text-transform: lowercase cannot properly handle Turkish or Azeri text, as it unconditionally maps both “I” and “İ” to “i”, not to “ı” and “i”. Proper support to them has been promised for Firefox 14, presumable to be used when the content language has been suitably defined using the lang attribute, but it will take a long time before such processing is common across browsers. In server-side processing, it is usually very easy to deal with this as a special case.
Does not seems like text-transform should cause any issues
http://jsfiddle.net/m9fpX/
are you setting
<meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
Related
I generate web-page by Razor and sometimes browser show me question marks instead of one random unicode character.
For example:
I think, this question mark is displayed in place where the first byte of two-byte unicode character is in the one tcp-package and the second byte of character in the other tcp-package. But why browser does't paste them correctly?
All files encoded by utf-8. There is <meta charset="utf-8">.
Update
Question marks dependent on page content. If I change content before question mark, it may disappear or move to other place (replace other character)
Encoding the characters in UTF-8 encoding scheme is not the only thing you should consider while working with encodings. Font family also plays a great role in this thing for rendering the correct graphics for all of your characters; characters are after all just glyph drawn by graphics. Unicode takes care of all of the bytes (1, 2, 3, 4 which ever size) of your characters and shows the correct character on your screen; if your framework or font-family supports the glyph.
In your website, the font-family; probably a custom loaded, does not support this character, (or the code page to be more specific) that is why browser has to fall-back to display a question mark. You're also saying that the character is randomly chosen, so that defines the problem, for being a font-family based problem. I would advise that you try out your application in 'Segoe UI' font-family and see if that works; because that probably would work.
Apart from my suggestion, please make sure that the font-family does support that code page where this character exists. Otherwise, it will display a question mark.
For some reason, the spaces between words on a font that I am using disappeared. See:
http://www.fantasynews.com/
I'm using Twitter Bootstrap slightly modified to use Google Web fonts. The font in question is Oswald served up by Google web fonts:
http://www.google.com/webfonts/specimen/Oswald
And the spacing appears normal for me there.
I'm no CSS guru, but I have touched nothing in my code that should alter the way spaces are displayed. I don't know of anything that should target spaces in particular. I feel like this is some dumb mistake that I'm overlooking but I'm clueless. If I view the source, the spaces are clearly there as well as the spaces clearly being there when I inspect the element, in case some bit of javascript was playing a trick.
I am using the latest version of Chrome, although this also appears in Firefox.
I should say that the spacing problem appears specifically for the title in the boxes under latest player news
I forced it by adding word-spacing: 0.25em to my CSS, but I'm not yet 100% sure that fixed it in every browser. It's unfortunate that Google doesn't have an obvious way to link to a particular version of a font so you could be confident it won't change from under you.
Removing font-weight: normal; fixes the spacing (there are 2 instances being applied to it, Inspect Element and you will see them)
EDIT: This is a bad font, you should choose another one! It looks fine bold, but the normal version is awful.
Same problem here, i applied another font to the online website and pray for a solution :(
It may be a wrong encoded file on google's servers. Nobody's safe from minor issue like these, even the guy who encode typos in the webfont service.
I usually use Firefox(newest) for Ubuntu 12.10. Everything looks fine there. In Chrome however, your fonts are most definitely squished. I personally would choose a different font that renders more consistently. If you want to learn more check out Mozilla's MDC Kerning page to get started.
The main way that I use kerning is with the letter-spacing property.
h2 {
letter-spacing: -0.1em;
}
To say that this addresses "kerning" would be false. This actually affects "tracking". The only difference between the two is that kerning is the relationship between two character and tracking relates to a block of text.
I have an HTML file which I want to load in a QWebView. The header looks something like:
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
</head>
The body text is mixed Latin and Japanese characters.
The page displays perfectly in Chrome, but all of the Japanese characters are replaced with □ when the page is displayed in a QWebView.
QtWebKit seems to use the same system as used by QTextCodec to handle conversions between unicode and other charsets (please correct me if I'm wrong on this) and I'm therefore working on the assumption that QtWebKit can support Shift_JIS.
As a test, I've tried adding the specific unicode for a kanji character (e.g. ぁ to display ぁ) to my HTML file. I get the character properly rendered in Chrome, but it also displays as □ in a QWebView - I'm not sure whether this means I can trust the Shift_JIS to unicode conversion in Qt, but it certainly means I can't assume that it is the cause of the problem.
I'm not sure where to go from here; any suggestions as to solutions or other areas to investigate would be much appreciated.
Turns out I've been over-thinking this one, there is in fact a pretty simple solution:
When confronted with Kanji characters which the current font is unable to display, Chrome is clever enough to fall back to a font which does support those characters (on my Win 7 PC the default Kanji font is MS Gothic).
QtWebKit does not have this feature, and hence it is necessary to explicitly specify (in CSS) a Kanji-capable font for the areas which need it.
I have a div that is too narrow to text-align:justify (gaps too wide), but yet looks un-uniform when right- or left-justified, because then there is a large gap at the end of lines. Left-justified looks best, but could I use hyphenation, like in books? Using CSS?
You can use hyphens: auto provided that you have declared the content language in HTML, e.g. using <html lang=en-US>.
Browser support is still limited but getting better, see
http://caniuse.com/css-hyphens
For good quality, you may need to manually control hyphenation e.g. by using soft hyphens () in words that might otherwise be hyphenated wrong.
Hyphenation is language-dependent; you can't just put overflowing characters on the next line and get the same effect that you do in books. Hyphenation rules are actually pretty complicated (see http://dictionary2.classic.reference.com/writing/styleguide/division.html), and the only way that you can do it properly (like in books) is either manually or via a client-side or server-side script; I'm pretty sure it can't be done using only css.
You might want to use something like http://code.google.com/p/hyphenator/
For hyphenation in html, there are javascript programs to add what's needed to the text. such as http://code.google.com/p/hyphenator/
Support for brower buildin hyphenation is unreliable and improvement in its support is doubtful.
True or not: We should always use proper capitalization and never put whole sentences in all-uppercase. If we must do so, we should use CSS for this task."
Should we use the CSS property text-transform for other cases if we need them?
(Note that I'm not talking about HTML tags, I’m talking about text content)
Links to read:
http://blog.mauveweb.co.uk/2009/01/14/dont-use-uppercase-in-html/
http://www.webaim.org/techniques/fonts/#caps
Huh? For normal text? That sounds like a ridiculous idea to me. Every language has its rules about what's lowercase and what's uppercase. Why would one want to divert from that?
Update: Sorry Jitendra, I didn't read your update closely. Now this
I head Screen reader spell letter by letter if we use UPPERCASE.
could well be - say, for USA to be spelled like U S A. I could imagine some screen readers do this. But this would only mean not to put words in ALL CAPS - which is a rule you would want to follow anyway.
Having all text in lowercase and uppercasing the right words through text-transform, you would have to put a CSS class on every word that needs to be capitalized - extremely cumbersome, would result in horribleHTML soup, and wouldn't make sense. Just use normal capitalization, and don't use all caps.
You should write content of a page with proper grammar, spelling, and capitalization just as you would in an essay. Navigation and logos should start with an Uppercase (or if it's a name, the proper spelling for the name, e.g. iPhone, not Iphone or IPhone.) Only use CSS capitalization for stylization. So, if you want your site's name to be in all caps (MY WEBSITE) use CSS to make it all caps, but in the HTML make sure it's proper (My Website).
Hope this helps!
It's generally a good idea to concentrate on what's easy for people to read. Almost always, for almost all sorts of information presentation, conventional typographic rules for the language of the site are appropriate, and you should not do anything different without having a really good reason.
The W3C states that all XHTML elements and attribute names should be in lowercase:
XHTML documents must use lower case
for all HTML element and attribute
names. This difference is necessary
because XML is case-sensitive e.g.
<li> and <LI> are different tags.
As for web page content in between tags, of course it is not necessary.
Jaws does not spell out words if they are recognized as English words. FOR EXAMPLE "THIS IS PRONOUNCED NORMALLY." sounds the same as "This is pronounces normally." When dealing with abbreviations capitalization matters. For example "usa" is pronounced phonetically as one syllable. “USA” is pronounced as “u s a” Made up words tend to be pronounced the same regardless of capitalization, for example “FDIOSUF” is pronounced the same as “Fdiosuf”
I'm not talking about HTML TAG i'm talking about text content? I head Screen reader spell letter by letter if we use UPPERCASE.
my question was "Should we always use lowercase text in web page's content?" and use css text-transform for other cases if we need.
Just use natural text, as you did in your SO question. Screen readers will generally read ALL UPPERCASE as individual letters, as such text is generally an acronym (it'll likely vary from reader to reader - some handle things more intelligently than others, and may be able to figure out that a whole sentence isn't likely to be an acronym).
You don't have to lowercase every letter, though - a screen reader shouldn't have any problem with "This Is A Sentence."
UPPERCASE text that isn't an acronym should be done with CSS's text-transform: uppercase;.
It has nothing to do with screen readers. For actual content, you should use normal capitalization. For element names and attributes, you must use lower case if you're using XHTML, because it's case-sensitive and the spec says the tag names and attribute names are lower case. These are two completely different things (content vs.markup).
Edit Re your edited question: You should avoid incorrect use of ALL UPPER CASE TEXT (that would be an example of incorrect use), because screen readers may well spell that out on the theory that it's an acronym like HTML or W3C. But not doing ALL CAPS is not the same as doing all lower case. Use initial capitals at the beginnings of sentences, etc. Don't use ALL CAPS for emphasis, use <em> (or <strong>, depending on the type of emphasis). Doing so marks up your text semantically, which actually helps the screen reader do its job (by allowing it to put emphasis where it should be put).
yes you should, if you would like to modify the text letters use the css property text-transform http://www.quackit.com/css/properties/css_text-transform.cfm