No. What I mean is that HTML should contain a page’s content - all the content, and nothing more. That way, an HTML document is perfectly useful on its own, and can be parsed to provide all the content of a page. All stylistic elements should be inserted using CSS.
It’s not great for screen readers — uppercased text will be read out as individual letters (like abbreviations).
FWIW, every screen reader and speech synthesizer that I’ve ever seriously used for web browsing is smarter than that. I don’t frequently use Mac VoiceOver though, and when I was an iOS user, I didn’t do a lot of web browsing on my iPhone. So maybe it’s just a problem with Apple’s own speech synthesizer.
I read the title and thought “this is such a bad take.” I read the post and thought it made some sense.
I’m taking from this that the author is considering navigation and menu items as “content” - this seems like the wrong term entirely. I think this was my initial confusion.
I think of “content” as the actual meat of a blog post, page, article or even comment. Usually paragraphs or sentences, etc. Controlling uppercase with CSS seems bonkers in this context. Those writing content (as I know it) should not ever have to worry about CSS, it’s a different concern.
While the author does acknowledge it’s okay to uppercase when it makes semantic sense, the title terminology says something different. Or maybe I’m crazy and “content” just means anything that is displayed on the screen?
A very common case for all-caps content is going to be stuff like section titles within text. Other ones could include names in citations, figure descriptions, certain types of emphasis for technical terms, and so on.
These often come down to stylistic differences in a way where a new designer reworking your choices of typefaces or design could decide that something now needs small caps, to be title-cased, and so on. For these, you want CSS to be handling things, otherwise a change in design means you now need to re-edit all your content to work with it.
Semantic differences would imply that moving from uppercase to lowercase (or from lowercase to all caps). For example, “getting your PIN stolen” has a different meaning from “getting your pin stolen.” This example is also partly why you can often pick a small-caps font variant, which gives you the uppercase look without impacting the meaning.
The text-transform property is not reliable for some locales; for example, text-transform: uppercase won’t work properly with languages such as Irish/Gaelic. For example, App Size in English may be capitalized via text-transform: uppercase to APP SIZE but in Gaelic this would change Meud na h-aplacaid to MEUD NA H-APLACAID which violates the locales orthographic rules, as it ought to be MEUD NA hAPLACAID. In general, localizers should make the decision about capitalization. If you want to display WARNING, add a string with that capitalization, and explain it in the localization note.
The examples they give here are only for Gaelic, but I would imagine there is more than 1 language where no font is going to encapsulate the orthographic complexities of planet Earth.
Not to mention how many custom fonts it might take to handle all of these (which are probably already present as best as possible on the end user’s computer) results in more web page bloat.
Thank you for following up, TIL. I’m still unconvinced about “never manipulate case with css” but the rest of your remark about I18n and to be more precise—only use text-transform for certain lang—makes absolute sense. Given that so many web sites/apps don’t even support I18n to begin with IMO the benefits of using it (s. ferd’s comment) outweigh the potential negatives. Once you decide to go all in on I18n and support as many languages as possible you’ll usually run into many many other cases where most I18n implementations will fail you one way or another.
This is one of my pet peeves. On the other hand, I regularly get tripped by CSS not having a keyword for “sentence case”. Also, if you’d like to read more on the idiosyncrasies of this property and the implementation(s), there’s a CSSWG thread
A very logical extension to the rule that “your HTML should make semantic sense on its own.”
I don’t see how semantic HTML is related to the author’s recommendation of using the CSS rule. Do you consider CSS to be a part of HTML?
No. What I mean is that HTML should contain a page’s content - all the content, and nothing more. That way, an HTML document is perfectly useful on its own, and can be parsed to provide all the content of a page. All stylistic elements should be inserted using CSS.
Aha, got it. Makes sense from that perspective.
FWIW, every screen reader and speech synthesizer that I’ve ever seriously used for web browsing is smarter than that. I don’t frequently use Mac VoiceOver though, and when I was an iOS user, I didn’t do a lot of web browsing on my iPhone. So maybe it’s just a problem with Apple’s own speech synthesizer.
Isn’t Voiceover considered to be kinda meh anyway? I thought most people who use screen readers used NVDA or JAWS?
I read the title and thought “this is such a bad take.” I read the post and thought it made some sense.
I’m taking from this that the author is considering navigation and menu items as “content” - this seems like the wrong term entirely. I think this was my initial confusion.
I think of “content” as the actual meat of a blog post, page, article or even comment. Usually paragraphs or sentences, etc. Controlling uppercase with CSS seems bonkers in this context. Those writing content (as I know it) should not ever have to worry about CSS, it’s a different concern.
While the author does acknowledge it’s okay to uppercase when it makes semantic sense, the title terminology says something different. Or maybe I’m crazy and “content” just means anything that is displayed on the screen?
A very common case for all-caps content is going to be stuff like section titles within text. Other ones could include names in citations, figure descriptions, certain types of emphasis for technical terms, and so on.
These often come down to stylistic differences in a way where a new designer reworking your choices of typefaces or design could decide that something now needs small caps, to be title-cased, and so on. For these, you want CSS to be handling things, otherwise a change in design means you now need to re-edit all your content to work with it.
Semantic differences would imply that moving from uppercase to lowercase (or from lowercase to all caps). For example, “getting your PIN stolen” has a different meaning from “getting your pin stolen.” This example is also partly why you can often pick a small-caps font variant, which gives you the uppercase look without impacting the meaning.
Unless you need i18n, then never manipulate case with css, or at least make sure you only ever do it when
.enis present on thebodyor something.Care to elaborate a bit more? ferd gives a few examples supporting the OP. Same arguments would apply to languages like German and Russian.
Taken from MDN:
The examples they give here are only for Gaelic, but I would imagine there is more than 1 language where no font is going to encapsulate the orthographic complexities of planet Earth.
Not to mention how many custom fonts it might take to handle all of these (which are probably already present as best as possible on the end user’s computer) results in more web page bloat.
Thank you for following up, TIL. I’m still unconvinced about “never manipulate case with css” but the rest of your remark about I18n and to be more precise—only use
text-transformfor certainlang—makes absolute sense. Given that so many web sites/apps don’t even support I18n to begin with IMO the benefits of using it (s. ferd’s comment) outweigh the potential negatives. Once you decide to go all in on I18n and support as many languages as possible you’ll usually run into many many other cases where most I18n implementations will fail you one way or another.This is one of my pet peeves. On the other hand, I regularly get tripped by CSS not having a keyword for “sentence case”. Also, if you’d like to read more on the idiosyncrasies of this property and the implementation(s), there’s a CSSWG thread