I am having problem with css property of text:transform. When I set it to capitalize, it behaves differently in IE7 and IE8. The Product title of page[1] shows apple tree 'Gala' in other browsers while in IE it shows apple tree 'gala' . Note the 'g' letter after quote. I want the 'g' to be capital in both IE and other browsers.
Is there any hack or extra setting I need do, to get it working in IE ?
[1] - http://shop.shootcare.co.uk/pomonafruits/find/apple-tree-gala-apl026?path=&ref=mall
The property text-transform is seriously under-defined in CSS specifications. Its CSS 2.1 definition does not even specify what “word” means. In computer contexts, “word” as a unit of text means just a maximal sequence of non-whitespace characters, so in your case, the string 'gala' with the apostrophes included would be one word, and its first character is the apostrophe. So it could be argued that IE is most right here, but other browsers have adopted other interpretations.
The CSS3 Text draft proposes to change or clarify the meaning so that the first letter (which would really mean “letter or digit”!) would be affected. So this would make the g in 'gaia' capitalized. But it still does not define “word”, e.g. whether “cutting-edge” is two words or one, or how many words there are in “rock’n’roll”.
The conclusion is that almost any method for capitalizing words is more reliable than the CSS way. If possible, modify the software that generates the pages so that it performs the desired operation server-side, according to the rules you prefer. Even using JavaScript is safer than CSS here.
well the capitalize transform works differently on some browsers, for example for some browsers java-script would return Java-Script, some others would just return Java-script.
also keep in mind capitalize doesnt work with the rest of the letters of a word, it only changes the first one, so if you have the word intERNET, it would return IntERNET, leaving the reast as it is.
so my wild guess, is that ie7 & ie8 are taking 'gala' as a word byt making the ' the first character, so they are trying to capitalize a ' returning the same ', im dont know if there is a hack to it, but that might be something to get you started, try using gala instead of 'gala' just to test, and then see if there is a way to ignore the ' while capitalizing.
Related
I found this article about hanging punctuation:
http://webdesign.tutsplus.com/articles/getting-the-hang-of-hanging-punctuation--cms-19890
and this link in the comments: http://dabblet.com/gist/9623025
It's a really nice idea, and it would be an awesome way to hang soft hyphens generated by some tool like Hyphenator or Hypher. I started playing around with Hypher and encapsulated the hyphens in a span...
Then I realized I don't know how to style soft hyphens.
This code should make an hyphen red, but of course the one in span is not breaking a word, so the browser doesn't show it:
<style>
.box{
width:40px;
background-color:yellow;
}
.hyphen{
color:red;
}
</style>
<div class="box">
<p>aaaabbbb<span class="hyphen"></span>cccc</p>
</div>
http://jsfiddle.net/5LazU/
Is there any way to do it?
It is somewhat unclear what the question is about, so I will address different interpretations of it.
The hyphens introduced by a browser’s automatic hyphenation (due to the use of the hyphens property) cannot be styled as separate entities (i.e., in a manner that differs from the style of the surrounding text), since they do not constitute elements or pseudo-elements.
Styling SOFT HYPHEN characters in HTML is a different issue, with browser-dependent answers. The answer does not depend on the method of entering SOFT HYPHEN (as a raw character vs. the reference vs. a numeric reference), since they result in the same data in the DOM: But it depends on wrapping the character in an element, as in the question.
The code in the question causes a red hyphen to be displayed on Firefox and on IE, but on Chrome, there is no hyphen after “bbbb”, so I guess the code was tested on Chrome. This appears to be a bug: the element is treated as allowing a direct line break without inserting a hyphen.
The issue of “hanging punctuation” is something completely different. The reason why hanging punctuation techniques word for quotation marks (which is what the linked documents contain) is that the marks appear at the start and at the end of a segment of text. Browser-inserted hyphens are different, and the key thing there is that the browser analyzes how many characters will fit on a line before it inserts a hyphen (due to automatic hyphenation or as a result of rendering SOFT HYPHEN as a visible hyphen). I don’t see how there could be a way to intercept this unless the browser provides an API for the purpose.
I recently bought a font and wanted to embed it into my website using web fonts.
Now the problem is: After buying it, I realized that the font is missing the umlauts, such as ä, ü and ö, so it shows an empty space instead of the (missing) character.
Is there a way to prevent this? Like tell the css to use another font for the missing characters? Or would I have to edit the font itself?
Because there is no "easy", or clean way around this except remodeling the font files, here's a small JS script to replace extended ASCII chars with a <span>. (One could only do this for the exact, required characters, but you'll propably end up asking yourself the same question again once you accidentally come across another character that's not supported.)
JS only on example text:
"Hêllo wörld. ÄÖÜßäöü".replace(/([\x80-\xff])/gi, '<span class="arial">$&</span>')
Result:
H<span class="arial">ê</span>llo w<span class="arial">ö</span>rld. <span class="arial">Ä</span><span class="arial">Ö</span><span class="arial">Ü</span><span class="arial">ß</span><span class="arial">ä</span><span class="arial">ö</span><span class="arial">ü</span>
jQuery:
$('.webfont').each(function(){
this.innerHTML = this.innerHTML.replace(/([\x80-\xff])/gi, '<span class="arial">$&</span>')
});
The nodes with .webfont should only contain text, although it should also work in most other cases.
There is no acceptable way to prevent this. Use a different font. (It is possible that there is an extended version, with higher fee, of the font you bought.) The font should be selected so that it contains all characters, at least all letters, that you may need in the text.
It is possible to use different fonts for different letters in a word, using various techniques (#font-face with range settings being the most elegant, but with limited browser support). However, it means a typographic disaster. Especially if the text contains e.g. both “ü” and “u”, there is usually a striking mismatch.
Editing the font itself is technically possible using a font editor, but normally illegal unless permitted in the font license or in exemptions to copyright in applicable legislation.
Please take a look in Firefox at the development site here.
The same phrase "Accountantskantoor verschaeren-mertens" is shown twice, once in the sidebar and once in the upper right corner. As you can see the line breaks at different positions. I've tested in Chrome, IE and Firefox and this only occurs in Firefox.
Any thought on how to make it consistent? I've tried the following but it didn't work.
word-break: normal;
This is rather mysterious, because Firefox is clearly hyphenating the text in the upper right corner: there is a hyphen at the end of first line, indicating word division made. It’s not something that word-break would cause (it brutally breaks strings instead of proper word divisioon).
Yet there is nothing that suggests hyphenation in the code, unless I’m missing something.
But setting the following on the element prevents Firefox from hyphenating:
-moz-hyphens: manual
Presumably Firefox now has some defaults that cause automatic hyphenation in some situations (possibly -moz-hyphens: auto with some fancy selector). And since Firefox still does not use hyphens as the property name, the vendor-prefixed property needs to be used.
Setting the value to manual allows a break after a hyphen as well as the effect of soft hyphens. To disallow even them, use the value none instead.
The implementation of this feature differs in browsers so IMO the only solution is to use hyphenator.js There is also a
hyphenator wordpress plugin
Playing around with shjs in order to display line numbers, line breaks and spaces, i came across this: Using Pseudo-Elements for the ›hidden‹ characters it behaves just as expected (in Firefox): no line numbers, spaces or line endings get copied to clipboard.
As IE8 displays everything well, I was surprised it behaves different with copy+paste.
Copy+pasting a line from FF looks like so (which is fine):
config = ({
While the same, copied from IE8 reads:
14·config· =· ({¶
The same with Opera, btw.
Does anyone know which behaviour is the correct one, and if there is a way to teach the browser the desired behaviour?
Thanks in advance
Opera and IE are correct: There is no rule which forbids copying generated content. Mozilla’s behavior is btw one of the many reasons why you can’t use the <q> element …
Unfortunately, you can’t bring all browsers in line. Generated content is not part of the DOM and therefor not accessible per Javascript.
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