Beim Barcamp Klagenfurt habe ich einen Vortrag zum Thema HTML5 gehalten, habe den bald neuen Standard vorgestellt und Fragen dazu beantwortet soweit mir das möglich war. Einer der besten Einwürfe kam aber nach Ablauf der Redezeit von Heinz Wittenbrink, der anmerkte, das man nun ja wieder bei Tagsoup angelangt sei.

Wikipedia sagt dazu:

“Tag soup refers to formatted markup written for a Web page which is very much like HTML, but may not consist of correct HTML syntax and document structure. Because web browsers have historically treated HTML syntax or structural errors leniently, there has been little pressure for web developers to follow published standards, and therefore it is necessary that all browser implementations treat what looks like HTML as “tag soup”, accepting and correcting for invalid syntax and structure.”

Tagsoup ist also etwas, was außerhalb des Standards passiert, etwas was nicht spezifiziert ist und damit auch nicht kontrolliert werden kann. Das führt dann unweigerlich zu unterschiedlich funktionierenden Parsern, zu inkompatiblem HTML-Rendering.

Der X(HT)ML-Weg

Es gibt 2 Möglichkeiten mit diesen Problemen umzugehen, und wir kennen beide aus der Praxis bzw. aus möglichen zukünftigen Standards. XHTML übernimmt das XML-Verhalten und Parser brechen ab, sobald es auf einen Fehler im XHTML-Code stößt. Sämtliche Inhalte des Dokuments würden den Nutzern vorenthalten werden, eventuell nur weil sich ein &-Zeichen eingeschlichen hat oder ein vergessener Slash ein Dokument invalide macht.

Das macht in der Maschine-Maschine-Kommunikation Sinn, diese möchte keine fehlerhaften Daten übermitteln.

Der HTML-Weg

Im heutigen Web werden sowieso die meisten Dokumente mit einem Tagsoup-Parser gerendert, auch so ausgezeichneter XHTML-Content sofern er nicht mit dem Mime-Type application/xml versendet wird. HTML5 nimmt die Herausforderung von kaputten Webdokumenten an, legalisiert sie aber nicht.

So wird ein Teil der HTML5-Spezifikation sich nur dem Thema „Korrektur von Webseiten“ widmen und Parsern vorschreiben wie sie welchen Fehler korrigieren sollen.

Legalisiert werden sollen abschließende Schrägstriche in Elementen ohne End-Tag wie IMG oder LINK. Grund: Das Verbot richtete sich nach dem SGML-Parser, der einen Schrägstrich als Ende des Elements interpretieren würde. Ein solches Verhalten wäre inakzeptabel für die Browserhersteller gewesen, weshalb diese den Schrägstrich komplett ignorierten.

HTML5 beschreibt also eine komplett eigene Syntax, die weder mit HTML4 noch mit X(HT)ML übereinstimmt. Sie übernimmt Konventionen, die sich im Web herausgebildet haben ohne Rücksicht auf die Herkunft der Konvention. Jedes Element, jedes Attribut geht dabei durch einen strengen Rechtfertigungsprozess auf den ich später noch eingehen werde.

Photo: “Alphabet Soup Background” von Wiebe via istockphoto.com

Dies ist das erste Experiment mit einem artikelbasiertem Layout. Es wird vermutlich nur im Safari und im Firefox 3 richtig dargestellt.

So, Microsoft, here are we again. Starting from the beginning. You probably remember your attempt to break the web by rendering web pages in IE7 mode by default? Well, I do. We shouted at you, had several arguments and you changed your opinion. Great. In the meantime you produced a decent CSS2.1 browser (why bother what the cool kids at Apple and Mozilla and Opera do with their non-standard filthy CSS3).

To be clear on that: I prefer a decent CSS2.1 over a badly implemented CSS3 browser every time. What you introduced as an alternative to the IE7 default mode was a button to force the browser into compatibility mode if a website was broken. Additionally websites could have the browser render them in compatibility mode if they used HTTP metadata, which is fine.

What is not fine is, that you lied at us. Big time.

You wrote in your blog post introducing compatibility mode:

“We’ve decided that IE8 will, by default, interpret web content in the most standards compliant way it can. This decision is a change from what we’ve posted previously.“

Now you won’t do that. If enough people (enough is just a number which you didn’t tell us) want to see a site in compatibility mode this is reported to Microsoft and then back to all IE8 instances which will then use IE7 rendering mode. That means Microsoft breaks the web again. There is no reason for doing that. Most people won’t see any differences in IE8 behaviour from other browsers.

What you did with IE8 is great, but you betrayed the whole community. Well done. We trusted you, we promoted IE8, we tried to do everything to get IE8 out there and the message it brings. Now we are left with a browser where a arbitrary number of people can decide how the pages are rendered not web authors. This is bad.

Yes, I know that we can opt-in into standards mode with HTTP meta data, but that is not what anyone even at Microsoft can expect people to do. As we don’t know how pages are rendered the web will once again grind to a halt and we will have to optimize for IE7 years and years and years from now.

Please get serious about the web and web standards. It looks like IE8 is yet again a piece of scum instead of a browser. But that fits nicely into what IE6 became and IE7 still is. Get real Microsoft, get real and make a browser instead of just calling some random piece of software a browser.

Update

Chris Wilson, Platform Architect of the Internet Explorer Platform team at Microsoft (says his website), said in several tweets (1, 2, 3, 4, 5) that you shouldn’t have to opt in into standards mode and that the domain owner, according to the whois data, will receive an e-mail. They can then say “no, thank you” to the blacklisting.

This seems quite appropriate, the question is if those mails get to the right persons all the time. That could be a problem in larger organisations. That said, such an e-mail has yet to be seen (by me, that is), probably they will be sent out prior or after the launch of IE8.