Wozu braucht mein Browser eigentlich einen HTML5-Parser?

Veröffentlicht am 5. Juli 2010

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>
Inline-SVG

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.

Sinn und Style des Search-Inputs in HTML5

Veröffentlicht am 1. Juli 2010

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.

Warum HTML5-Feature-Detektoren und -Charts nicht wahnsinnig viel taugen

Veröffentlicht am 8. Juni 2010

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?

Hardware-Review: Toshiba NB305 Netbook + Ubuntu Netbook Edition

Veröffentlicht am 3. Juni 2010

Toshiba NB305-105

Ich brauchte spontan ein Netbook und habe mir das Toshiba NB305-105 geshoppt. Reviews versprachen eine Marathon-Batterie, ein großes Touchpad sowie eine verbraucherfreundlich-robuste Tastatur und, das kann man schon sagen, dass sich das Versprochene bewahrheitet. Ich habe zwar erst wenige Stunden damit verbracht, aber die Arbeit geht definitiv sehr angenehm von der Hand und der Akku scheint keine Anstalten zu machen, sich zu entladen. Die Verarbeitung scheint robust und schlecht sieht das Ding auch nicht aus. Von den Leistungsdaten her ein ganz durchschnittliches Netbook.

Doof, aber (so finde ich) nicht sooo dramatisch: Glossy Screen. Außerdem hatte ich ja keine Ahnung wie lästig Windows 7 sein kann. Zum Glück war das komplizierteste an der Installation der Ubuntu Netbook Edition (Lucid) das Vorbereiten des Installations-Sticks, den mein Desktop-Ubuntu aus unerfindlichen Gründen nicht recht befüllen wollte. Es gab auf dem Netbook selbst keine Probleme – der gefürchtete Intel GMA 3150-Grafikprozessor gibt sich lammfromm, die Webcam geht, die Functions Keys scheinen es zu tun und auch sonst kann man konstatieren: es läuft rund. Kann man empfehlen, das Teil.