Peter Kröner, Webtechnologie-Erklärbär

We need to reset HTML5 and start over. Dieses Zitat von Douglas Crockford sollte in den vergangen Wochen an den meisten von uns ein- oder zweimal vorbeigescrollt sein. Egal ob auf Konferenzen oder im Interview, der Javascript-Altmeister wird nicht müde, zwar einige Ideen von HTML5 zu loben aber auch ganz klar zu sagen, dass es seiner Meinung nach ein Schritt in die falsche Richtung ist und eine Vollbremsung angebracht sei. Warum ist das so?

Das Problem, das HTML5 löst (nämlich dass bisherige Web-Technologien ein unzureichendes Rüstzeug für Webapps sind) ist laut Crockford nicht das Problem, das dem Web unter den Füßen brennt – vielmehr müsste Sicherheit die Top-Priorität genießen. Heutige Webbrowser machen es nämlich Übeltätern recht einfach: jedes Script, das auf einer Website läuft, darf alles – es darf Cookies setzen und auslesen, es darf die Website selbst verändern, es darf den User bitten sein Passwort einzugeben und vieles mehr. Sobald es einem Angreifer also irgendwie gelingt, einen <script>-Schnipsel irgendwo auf einer Website einzuschleusen (z.B. auf einer Profilseite in einem sozialen Netzwerk), kann er den Browser eines jeden Besuchers dieser Seite übernehmen. Das nennt man Cross-Site-Scripting (XSS).

XSS ist eine der größten Sicherheitslücken des Webs und gleichzeitig auch eins seiner besten Features, denn erst die umfassenden Privilegien für Scripts machen es möglich, Dinge wie Google-Maps, Facebook-Buttons und Flattr-Widgets mit zwei Zeilen HTML (besagten <script>-Schnipseln) einzubauen. Die Scripts dürfen die Seite selbst verändern um ihre Buttons und Bilder zu platzieren, was man ja Google, Facebook und Flattr durchaus gerne erlauben, Datendieben aber gerne untersagen würde. So einfach ist es aber nun eben nicht und HTML5 verändert an diesem Zustand nichts – im Gegenteil, Technologien wie Offline-Speicher eröffnen interessierten Kriminellen neue, attraktive Angriffsziele.

Douglas Crockford vertritt die Auffassung, dass Sicherheit wichtiger als neue HTML-Elemente sei. Seiner Ansicht nach gehört die HTML5-Entwicklung gestoppt bis ein besseres Sicherheitsmodell für den Browser erdacht und implementiert wurde. Danach sollen die Einzelteile von HTML5 Stück für Stück den neuen Sicherheitsvorgaben angepasst und re-implementiert werden. Alles andere verschlimmere nur die XSS-Problematik, die ohne Änderungen am Browser selbst nicht in den Griff zu kriegen sei.

Ich persönlich tu mich mit diesem Ansatz schwer, gleichwohl an der Diagnose, dass XSS ein Problem ist, natürlich nicht zu rütteln ist. Aber man muss auch sehen, dass dass das Kind HTML5 bereits in den Brunnen gefallen und auf dem Weg nach unten mindestens schon zum nervigen Teenager herangewachsen ist. Es ist schwer vorstellbar, dass da noch irgendeine Form von Reset möglich sein soll, zumal bekannt ist, wie lange es dauert, bis sich eine Technologie in wirklich allen Browsern auf breiter Front etabliert hat. Außerdem ist nicht zu vergessen, dass HTML5 ja selbst das Ergebnis eine geplanten Web-Resets, nämlich XHTML 2 ist – das Web ist eben nicht die Bühne für Resets oder Revolutionen, sondern viel mehr ein Ort der graduellen Veränderungsprozesse. Vor diesem Hintergrund habe ich so meine Probleme damit, We need to reset HTML5 and start over als einen ernst gemeinten, konstruktiven Vorschlag anzusehen. XSS reparieren, gerne – aber dafür HTML5 stoppen, das wird schon sehr schwierig.

Anlässlich der der Ankündigung, dass der Firefox 4 erstmals standardmäßig einen HTML5-Parser verwenden wird (für Webkit wird auch bereits einer entwickelt), erreichten mich diverse Fragen was das denn jetzt bedeuten würde. Wenn die Browser von heute keinen HTML5-Parser verwenden, was haben sie denn dann? Immerhin können die doch alle – mit Ausnahme des IE – HTML5-Elemente wie <canvas> und <video> darstellen, oder? Richtig ist, dass ein Oldschool-HTML-Parser und ein Parser nach den Regeln der HTML5-Spezifikation sehr viel gemeinsam haben und die wenigen Unterschiede nur selten sichtbar werden. Aber ganz überflüssig sind HTML5-Parser natürlich nicht.

Der Ist-Zustand

Die ersten kommerziellen Browser hatten das Problem, dass HTML als eine SGML-Anwendung konzipiert ist und eigentlich einen sehr komplexen Parser benötigt (SGML ist so etwas wie ein komplizierterer Vorfahre von XML). Für den Einbau eines SGML-Parsers hatte man damals mitten im Browserkrieg aber keine Zeit und so entwickelt man eigene, nicht dem dem Standard entsprechende Parser für HTML-Dokumente. Sie zeichneten sich durch eine hohe Fehlertoleranz aus und bewährten sich letztendlich – jeder moderne Browser verwendet heute zur Verarbeitung von HTML solche Nichtstandard-HTML-Parser.

Im Bemühen um größtmögliche Kompatibilität glichen die Kombattanten des Browserkriegs ihre jeweiligen Implementierungen miteinander ab, so dass also heute alle Browser ungefähr gleich weit von den Standards entfernte Parser haben. HTML5 löst dieses „Problem“, indem einfach die bestehende Parser-Realität zum Standard erhoben und nur minimal erweitert wird. Das funktioniert recht gut, weil zwischen den Browsern bereits Kompatibilität besteht und es relativ wenige Neuerungen gibt.

Was gibt es neues?

Das, was in den HTML5-Spezifikationen über Parser festgelegt wird, entspricht in weiten Teilen dem, was jeder Browser schon heute kann. Anders gesagt: So viel neues gibt es da gar nicht, denn ein HTML5-Element wie <canvas> unterscheidet sich ja, was die Verarbeitung des HTML angeht, nicht fundamental von einem <div>. Die mit dem Element stattfindenden Interaktionen durch den Nutzer sind vielleicht andere, aber letztlich sind beide nicht mehr als eine Node im DOM-Tree und ein Rechteck auf dem Bildschirm.

Die Parser-Realität anzuerkennen und den Ist-Zustand zu standardisieren bringt Zweierlei: Erstens ist es den Browserherstellern möglich, Ihre Implementierungen weiter aneinander anzupassen, sofern es noch nach Jahren des Abschreibens noch Differenzen gibt. Und zweitens gibt es einige wenige Parser-relevante HTML5-Features wie etwa das <math>-Element und Inline-SVG:

<p>
    Das hier ist Inline-SVG:
    <svg width="250" height="50">
        <rect width="250" height="50" fill="green" stroke="black" stroke-width="8" />
    </svg>
</p>

Solcherlei Extravaganzen, wie in diesem Fall die Einbettung in XML in HTML, funktionieren nur mit einem HTML5-Parser. Normale neue Elemente wie <canvas> und <section> sind von der Parser-Frage nicht betroffen, weil sie für den bloßen Aufbau eines Dokuments keine besondere Bedeutung haben. Hiervon ausgenommen ist der Internet Explorer < 9, der aufgrund seiner etwas anderen HTML-Verarbeitung mit unbekannten Elementen noch so seine Probleme hat.

HTML5-Parser jenseits des Firefox 4

Der HTML5-Parser wird zwar erstmals im Firefox 4 standardmäßig aktiviert sein, doch vorhanden ist er auch schon in Version 3.6. Dort kann man ihn aktivieren, indem man unter about:config den Schlüssel html5.enable auf true stellt. Wirklich etwas davon haben wird man nur, wenn man Seiten ansteuert, die entsprechende Features auch verwenden – sieht man einmal von möglichen Abstüzen der experimentellen Software ab.

Wer selbst ein Projekt mit HTML5-Parser anschieben möchte findet beim html5lib-Projekt Implementierungen in Python und PHP. Eine Java-Implementierung, die auch Basis des Firefox-Parsers ist, stellt validator.nu bereit.

Das in HTML5 eingeführte Search-Input (<input type="search">) ist im Prinzip ein Formularelement, das sich nur durch sein Aussehen von einem normalen Textfeld unterscheidet:

The difference between the Text state and the Search state is primarily stylistic: on platforms where search fields are distinguished from regular text fields, the Search state might result in an appearance consistent with the platform's search fields rather than appearing like a regular text field.

Webkit-Browser sind bei der Implementierung von Search-Inputs Vorreiter und haben die bemerkenswerte Eigenschaft, überhaupt gar kein Styling von Suchfeldern zuzulassen! Das folgende CSS resultiert nicht in einem Eingabefeld mit rotem Rahmen:

input[type=search]{
    border:2px solid red;
}

Francesco Schwarz hat nun herausgefunden, wie man diese Blockade lösen kann. Die CSS3-Eigenschaft appearance (Spezifikationen, Artikel) ermöglicht es, HTML-Elemente wie Teile des System-Interfaces zu gestalten oder eben eine solche Gestaltung auch aufzuheben. Um also ein Suchfeld mit rotem Rahmen zu versehen, muss man (zumindest bei Webkit-Browsern) appearance zurücksetzen:

input[type=search]{
    appearance:none;
    border:2px solid red;
}

Dieser Reset funktioniert zwar auch nicht perfekt (das Lupen-Icon bleibt erhalten) aber immerhin kann man so zumindest ein wenig eigenes Styling unterbringen. Aber es bleibt die Frage, warum sich überhaupt diese Mühe machen sollte.

Meiner Interpretation nach ist das Search-Input im Prinzip ein Präsentationselement wie <font> und <blink>. Einerseits kann ich schon nachvollziehen, was mit dem Element erreicht werden soll – Web- und Systeminterfaces zusammenzuführen ist ein hehres Ziel. Aber sind nicht eigentlich Gestaltungsfragen der Job von CSS? Wäre nicht so ein Suchfeld-Wie-Im-OS-Styling genau das, wofür es appearance gibt? Den Webkit-Entwicklern kann man aus dem absonderlichen Styling-Verhalten des Search-Inputs auch keinen Strick drehen, da es nicht so aussieht, als sei irgendwo genauer spezifiziert, wie genau sich denn das Element verhalten soll. Die ganz am Anfang des Artikels zitierte Passage ist alles, was die HTML5-Spezifikationen zum Search-Input zu sagen haben.

Und so bin ich bin bisher noch kein Fan von <input type="search"> geworden. Schwammig spezifizierte Präsentationselemente sollten eigentlich den HTML-Friedhof bevölkern und nicht in HTML5 herumgeistern.

Ergänzung: Eric Eggert zwitscherte mir gerade, dass man bei Apple mit dem Search-Input tatsächlich sogar noch mehr macht als den Style zu verbiegen. Eine Reihe von zusätzlichen HTML-Attributen rüstet Funktionen aus den Suchboxen des Mac-Betriebssystems nach, was dem Search-Input durchaus Sinn verleiht. An der Kritik an den HTML5-Spezifikationen ändert der Alleingang eines Browserherstellers (mag er noch so sinnstiftend sein) aber natürlich nichts.

Weil im Moment Diagramme wie dieses, Listen wie diese und Websites wie diese die Runde machen, sehe ich mich gezwungen tatsächlich trotz geplanter Blogpause diesen Post vorzuziehen. Es ist nämlich so, dass die Ergebnisse von HTML5-Feature-Detektoren nicht für mehr zu gebrauchen sind, als für Witze (Quelle). Der Grund: Die Detektoren prüfen via Javascript, ob Feature X implementiert ist, und nicht, wie es implementiert ist, also ob es schon zu gebrauchen ist. Und es ist zur Zeit sehr oft der Fall, dass eine HTML5-Funktion in einem Browser zwar vorhanden ist, aber entweder buggy oder gar nur ein reiner Platzhalter ist!

Ein gutes Beispiel ist das ImageData-Interface und dessen CanvasPixelArray, über das man bei einem Canvas-Element einzelne Pixel auslesen kann.

// Pixel für einen Ausschnitt auslesen
var imgData = context.getImageData(200, 80, 80, 80);
for(var i = 0; i < imgData.data.length; i++){
    // Mache irgendwas mit den Farbwerten der Pixel
}

Ist es in Webkit vorhanden? Ja! Ist es ein Array wie vom Standard vorgeschrieben? Ja! Sind denn auch Pixel drin? Nein (Update: Scheint nur bei mir der Fall zu sein, siehe Kommentare). Für einen Feature-Detektor wäre dies trotzdem ein vorhandenes Feature, das die volle Punktzahl abräumt. Noch ein Beispiel: Das dataTransfer-Objekt in Webkit-Browser, das normalerweise den Datentransfer in Drag&Drop-Operationen übernimmt.

// Drag-Start-Event, setzt das dataTransfer-Objekt
dragme.ondragstart = function(event){
    event.dataTransfer.setData('hallo', 'welt');
    event.dataTransfer.effectAllowed = 'move';
};

// Drop-Event
dropme.ondrop = function(event){
    alert(event.dataTransfer.getData('hallo'));
};

Ist es in Webkit vorhanden? Ja! Ist es ein Objekt wie vom Standard vorgeschrieben? Sind die Getter und Setter vorhanden? Ja! Kann man denn damit auch wirklich Daten transferieren? Nein. Implementiert Webkit das draggable-Attribut? Nein, stattdessen gibt es einen proprietären CSS-Hack.

Nur um das ganz klar zu machen: Dererlei ist für einen Detektor kaum zu ermitteln, insofern ist das hier keine Kritik an html5test.com und Konsorten. Und es ist durchaus sinnvoll, dass ein Browser halb fertige Features an Bord hat – wie soll man diese denn sonst testen? Klar ist aber auch, dass Feature-Detektoren eine für Webentwickler nicht brauchbare Aussage machen. Für hypende Marketing-Fritzen mag das gut genug sein, für Webworker eher nicht.

Ein letztes Beispiel: das <input type="date"> funktioniert in Webkit insofern, als dass es nicht wie gänzlich unbekannte Input-Elemente in ein <input type="text"> umgewandelt wird. Allerdings wird von dem Browser (anders als bei Opera) kein Datumspicker o.Ä. bereitgestellt. Dies ist zwar auch nicht explizit von den Spezifikationen vorgeschrieben, aber ob man hier von einer vollständigen Implementierung sprechen kann, ist zumindest diskutabel. Für einen HTML5-Feature-Detektor ist die Sache hingegen klar: Safari unterstützt diesen Teil von HTML5. Ich würde dieser Diagnose nicht unbedingt zustimmen.

Fazit: Die Schwarz-Weiß-Welt, die ein HTML5-Feature-Detektor oder HTML5-Support-Chart malt, existiert so nicht. Nicht mal im Ansatz. Für PR und Hype sind diese Dinger toll, für mehr nicht. Seid ihr hypende PR-Leute?