darph.plock

I ignored the HTML5-specification for the most part until now for several reasons. For one, in the holy religious war that is the endless discussion between HTML or XHTML I clearly stand on the side of the semantic and well-defined approach of XHTML. On the losing side, I might add, as the development of XHTML2 as been discontinued in favor of HTML5.

Mostly, this has been more of an emotional dispute. Whether you add trailing slashes on self-closing elements does not really matter, does it? But now that HTML5 is close to becoming actually used, it is time to take a look at it.

And oh boy, what a mess! HTML grew more or less organically. First being completely text-based and print-oriented, it had tags such as <b> to make text bold and <i> to make text italic. With time and the emergence of semantic web architectures, as it seems partly influenced by the „seperation of concerns“-philosophy of modern object oriented programming (see MVC), developers began to realize that „bold“ and „italic“ are just visual representations of concepts that go beyond reproduction of printed text on a screen. Screenreaders, that read text for the visually impaired, cannot read italic or bold text. The human voice does not have italic letters. What we can do, is alter the volume or pitch of our voice, to give words emphasis. XHTML was designed not only to introduce HTML-markup to the XML-realm (HTML is SGML and therefore a sister to XML) to increase its readability for machines, but also to clean up the language, and make it more semantic – in short to put meaning where there was only display. Something is <strong> and something has <em>-phasis – how you display it, is up to the client. Seems reasonable. Of course, in websites, <em> is typically printed in italic, but that’s because what we associate italicized text with that meaning, it’s not what the markup says how it should be printed. It’s in the CSS.

HTML5, which seems to have been designed by the Merkels of the W3C, completely ignores this approach and sinks back into the hole that is the print-centric HTML3. Yes, we have some nice new forms. But we also still have the iframe. But I want to concentrate on the text part here.

HTML5 has an <em>-phasis tag as well as an <i>-talic tag. Both have the same standard style sheet associated (font-style: italic). Both seem to convey exactly the same meaning, just that <em> actually is about meaning, while <i> is about visual representation.

I would like to repeat that, because it sounds vaguely important: HTML5 (re-)reintroduces the <i> tag with the expressed intent of marking text that should be printed in italic. How is that in any way semantic and what on earth does this have to do with markup?

The HTML5 Definition says:

The em element represents a span of text with emphatic stress.

This is good. It carries meaning. Whether this should be displayed as italic or pronounced in a squeaky voice is a matter of the client. And of the designer – after all, you might be inclined to design a site in which emphasis is to be displayed in big, red, visually screaming letters. It’s up to you as a designer: Use Markup for the meaning, use CSS for the visual representation.

But then the Web Hypertext Application Technology Working Group,  kind of shows us the finger by also defining an <i> tag:

The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose (content whose typical typographic presentation is italicized).

[…]

Some examples of spans that might use the i element include a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name, or some other prose whose typical typographic presentation is italicized.

„Typical typographic presentation“ – really? So, what if I have <em>-phasized in my markup? Isn’t that (deducted from the default style sheet of said element) typically italicized? Please, WHATWG, explain to me, how this carries any significance:

<p>This is <em><i>Spartaaaa!</i></em></p>

Are we really supposed to be writing markup like that? Why would we care about how something is typically printed? Yes, we care about it in our style sheets, but does the markup really need to know that? „Well, this part, it has some sort of significance, but, not really, coz it doesn’t deserve its own tag, like, you know, a definition or an abbreviation.“

The definition of the <b> tag that marks text that is typically bold goes even one step further in its confusion:

The b element represents a span of text offset from its surrounding content without conveying any extra importance; for example, keywords in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is bold text.

So, it’s bold. I put a visual clue on it, people shall recognize it. But it’s not important, nope, nope. Not important at all. Carries no meaning. I just wanted to put your attention to it for no reason at all. What are automated information aggregators and multimedia databases supposed to do with this information?

Well – if it’s important, use <strong>, if it’s not important, it does not need bold text. (Which context writes product names in bold anyway? I have ever only seen italicized text or having names put in „quotation marks“. But that is besides the point.)

Not only that the existence of the <i> and <b> tag makes no sense at all from a semantic point of view, the fact that they are closely linked to the semantic equivalents to <em> and <strong> will lead to an <strong><strong><b>epic</b></strong></strong> case of confusion among web monkeys: I am willing to bet a significant amount of money (let’s say a keg of beer) that more than half of all websites will confuse the two tag philosophies.

If people didn’t get the the difference between strict and transitional document declarations (look it up, if you have to) and still create new transitional websites (come on! it’s in the fucking DTD!), do you honestly believe they will get the difference? Do you really think this makes anything easier or better? If so, please explain the reasoning to me.

The HTML5 definition is completely botched – keeping the print-centric tags is backwards and plain stupid. I am surprised that we didn’t reintroduce the <u>-nderline-tag, for, you know, text that is typically underlined.

The new forms are nice and the <header> and <section>-tags are a smart addition. But don’t get me started on headlines. <h1> to <h6>? Are you serious? XHTML2 really had a smart, well-conceived and reasonable approach to nested sections and headlines. Yes, let the DOM and CSS figure the nesting out! This way I can use the same markup in my single entry page as well as in the archive listing (you know, blogs)! It’s smart, versatile and it works!

But no, for sake of backward-compatibility (really, guys, this is why Vista sucked!) we keep the old six-level-headline format.

HTML5 should not care about backwards compatibility: Make the browsers support two rendering options. Making HTML5 so that the old HTML4-crap validates totally misses the point of creating a new version in the first place. The popularity of the transitional document type shows that people won’t change their bad habits in web-design.

HTML5 was supposed to be clean and forward oriented, ready to support a semantic web architecture. It is not.