Die liebe Verwandtschaft: SGML, XML, HTML, XHTML und HTML5

Die HTML5-Empfehlung nähert sich mehr und mehr der Fertigstellung, was für mich Grund ist — Lust und Zeit vorausgesetzt — in loser Folge auf einige Aspekte des Drafts einzugehen. Für einige Verwirrung sorgt die Schleudertour der letzten Jahre, in denen XHTML1.0, 1.1 und 2.0 irgendwie als Nachfolger von HTML 4.01 durchzugehen schienen. Erst eine Übersetzung von HTML in ordentliches XML (endlich!) und dann diverse Erweiterungen des Entstandenen. Das klang logisch.

Damit wurden aber nicht alle glücklich: Vor allem Mozilla, Opera und später Apple präferierten einen Weg, der unter anderem stärker auf Abwärtskompatibilität setzte und man koppelte sich von der W3C-Arbeitsgruppe als WHATWG ab. Später vereinten sich die beiden Entwicklungszweige wieder unter dem Dach des W3C und es entstand HTML5 quasi als Hülle um beide Zweige. HTML5 enthält HTML5 (wie soll ich das meinen Kindern erklären?) als Weiterentwicklung von HTML sowie XHTML5 als Nachfolger von XHTML2.0.

Je nach verwendetem Mimetype (text/html oder application/xhtml+xml) wird die eine oder die andere Sprache erwartet — ja, man muss hier Sprache sagen, denn es handelt sich bedauerlicherweise nicht nur um syntaktische Unterschiede, sondern um Unterschiede in Art und Umfang der Features. Dazu später mehr.

HTML5: “Feature-complete” ab Mitte 2011

Philippe Le Hegaret vom W3C sah sich nun offenbar gezwungen, in einem Infoworld-Interview klarzustellen, dass HTML5 noch nicht produktiv einsetzbar ist — was niemanden wundern dürfte, da es noch mitten in der Standardisierung steckt. Alle Features werden demnach erst Mitte 2011 fest definiert sein. Danach folgt noch die eigentliche Detailarbeit.

Trotzdem ist es klug, öffentlich noch einmal auf die Situation aufmerksam zu machen, denn eine breite Nutzung eines unfertigen Standards hat das Potenzial, eben diesen in seinem Ansehen und seiner Verbreitung schwer zu beschädigen.

Hinzu kommt, dass die Browser erhebliche Unterschiede in Qualität, Umfang und Performance der HTML5-Implementierung aufweisen. Einige teils sehr schöne Demos gibt es dennoch, z.B. hier bzw. ganze Sammlungen hier oder hier.

Weppy alias WebP

Kaum habe ich mich gestern (eher zufällig) ins Google-Imperium vorgewagt, rollt von dort aus schon wieder die nächste Sache an. Nachdem man vor einiger Zeit WebM vorgestellt hat — einen offenen, unter BSD-Lizenz stehenden Videocodec — hat man nun die statische Variante nachgeschoben. WebP stützt sich auf in WebM verwendetes Verfahren zur Kompression der Keyframes.

Ziel ist es, die Dateigröße von Bildern gegenüber JPEG noch einmal deutlich zu reduzieren, um Traffic zu reduzieren. Das soll natürlich ohne merklichen Qualitätsverlust von statten gehen. Das ist kein geringer Anspruch.

Nach einer Google-internen Untersuchung hat man bei gleicher Qualität in 1 Mio. Bildern durchschnittlich 39 % Volumen sparen können. Googles Beispielbildern nach macht WebP einen guten Eindruck. Unabhängige Untersuchungen kommen zu höchst unterschiedlichen Ergebnissen. Wahrscheinlich ist es noch zu früh, dies abschließend bewerten zu wollen, da die Entwicklung noch nicht abgeschlossen ist.

Interessanter ist die Frage, inwieweit sich ein von einem einzigen Player in den Markt geworfenes neues Format überhaupt durchsetzen kann, zumal man bislang praktisch nirgens Bedarf nach einer Innovation auf diesem Gebiet vernehmen konnte. Da hängt alles von den Browsern ab. Natürlich wird Chrome WebP in Kürze unterstützen und in WebKit dürfte es damit auch einfließen. Und damit in Apples Safari, Openmoko, Android, iPhone, Palm und bald auch Blackberry. Das ist der Weg über WebKit.

Aber es gibt einen zweiten: Da WebP die Bibliothek von WebM verwendet, dürften die Browser, die WebM unterstützen, bald auch das neue Grafikformat darstellen können. Dazu gehören dann Mozilla Firefox und Opera. Selbst für den Internet Explorer hat Microsoft angekündigt, ab Version 9 eine manuelle Nachinstallation zu ermöglichen. Ach ja, der Flashplayer wird das Format auch bald abspielen können.

Ich gehe davon aus, dass sich WebM auf breiter Front durchsetzen wird. Es ist technisch offenbar ausreichend, offen und YouTube wird darauf umgestellt. Mehr Argumente braucht man nicht. Damit und mit der Schützenhilfe über WebKit könnte WebP auf jeden Desktop und in jedes Smartphone kommen.

Es bleibt die Frage nach Googles Motivation. Sicher profitiert Google von eingesparter Bandbreite. Ich könnte mir vorstellen, dass Google sicher noch andere Funktionen einfallen, die man WebP angedeihen lässt wie z.B. für Suche, Indizierung und Tracking optimierte Metadaten und Ähnliches. Ich bin gespannt.

„Vielleicht wäre es einfacher, den Leuten erstmal zu erklären, dass sie ihre 12 Megapixel-JPEGs herunterrechnen sollen, bevor sie sie in 300 Pixel Breite in ihre Seite packen.“ (Autor vergessen, oder war ich es selbst?)

Chrome vs. Firefox vs. Safari vs. IE vs. Opera

Nicht, dass man es nicht hätte erwarten können, aber die Ergebnisse fallen überraschend deutlich aus: Lifehacker hat in einer Umfrage festgestellt, welcher Browser von seinen Lesern favorisiert wird.

Das kam dabei heraus:

Chrome hat offenbar im letzten Jahr stark zugelegt — Google hat jede Menge Nickeligkeiten und auch Bedenken bezüglich des Datenschutzes entschärft. Im Juni 2009 sah das Ergebnis der Umfrage noch so aus:

Tja, so kann’s gehen. Am erstaunlichsten finde ich allerdings den geringen IE-Anteil.

Nein, stimmt nicht.

Noch erstaunlicher finde ich nämlich, dass Lifehacker das mit einer Umfrage feststellen lässt anstatt einfach den User Agent der Visitors statistisch auszuwerten.

Vielleicht wäre das zu langweilig gewesen. Aber sicher hätte es da aussagekräftigere Daten gegeben.

© Copyright schulten.net