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

Es ist mal wieder so weit: Leser fragen, der Erklärbär beantwortet Fragen zu HTML5! Üblicherweise gebe ich auch gerne Antworten zu CSS3 und JavaScript, aber da gab es diesmal keine Fragen. Wenn auch ihr etwas wissen wollt: einfach eure Frage mailen, twittern oder mich sonstwie heimsuchen!

HTML5 Shiv für <main> in IE 9 und 10?

Sollte man den HTML5 Shiv auch für den Internet Explorer 9 benutzen? Der Internet Explorer 9 kennt ja das Main-Element nicht.

Der Shiv ist für den IE9 nicht zwingend nötig, obwohl er funktionieren bzw. nicht stören würde. In den alten Internet Explorern wird der Shiv benötigt, da deren Engines nicht in der Lage sind, für sie unbekannte HTML-Tags zu parsen. Normalerweise würde man erwarten, dass ein fehlertoleranter Browser unbekannte Tags (bzw. super-neue Tags wie main) einfach hinnimmt und daraus ein generisches Element ohne Funktion erstellt. Genau das macht der IE9 glücklicherweise und damit kann man auch ohne Shiv arbeiten – da das Element von Haus aus nicht viel macht, muss man nur an zwei Stellen nachbessern. Das kann man dem Shiv überlassen oder man kann selbst Hand anlegen.

Nachbesserung 1 betrifft die Styles. Laut Spezifikaktionen sollte ein Main-Element display:block haben, was es, wenn es ein dem Browser unbekanntes Element ist, nicht hat. Als zweites sollte man auch die automatischen ARIA-Mappings, über die das Element verfügen sollte, nachrüsten. Das bedeutet laut Specs ein role="main" pro Element. Mit diesen zwei Anpassungen ist das Element dann fit für den Einsatz im IE9. Aber wie gesagt: der HTML5Shiv macht das auch, d.h. wenn man ihn verwendet, ist man bereits auf der sicheren Seite.

Warum kein hgroup?

Weshalb wurde das hgroup-Element abgeschafft?

Weil es kaum benutzt wurde! Sinn und Zweck des Elements war, Unterüberschirften vor dem Outline-Algorithmus zu verstecken (der an sich ja schon etwas schwierig mit der Realität zu vereinbaren ist), was aber kein Browser je unterstützt hat und auf den W3C-Mailinglisten hat sich auch kein Webentwickler oder eingefunden, der etwas für das Element vorgebracht hat. So wurde es dann zur Löschung vorgeschlagen.

Allerdings ist zu sagen, das das hroup-Element im Moment zumindest noch in den Specs der WHATWG auftaucht und nur im W3C-Draft schon fehlt. Richtig „weg“ ist es also noch nicht, aber die Entscheidung scheint gefallen. Ich jedenfalls würde schon mal anfangen, hgroup zu vergessen. Es macht in keinem Browser etwas, niemand scheint es zu nutzen und allen ist es egal. Also weg damit.

Und selbst wenn es etwas im Browser machen würde: nur weil ein Element in den Spezifikationen steht, heißt das noch nicht, dass man es auch benutzen muss! Dort sind genug Tags aufgeführt, die kaum jemand im Sinne von HTML5 benutzt (<s>, <u> usw.). Und das ist völlig ok.

HTML5-Formularvalidierung

Ich möchte der Frage nachgehen, inwieweit es Sinn macht die bei HTML5 integrierte Pflichtfeld-Validierung heute zu nutzen. Was spricht gegen den Einsatz von HTML5 bei der Pflichtfeld-Validierung? Wie gehe ich am besten vor wenn Javascript deaktiviert ist?

Bevor ich die eigentlichen Fragen beantworte, möchte ich kurz darauf hinweisen, dass man eigentlich die HTML5-Formularvalidierung nicht nicht benutzen kann. So wie Formulare an sich in HTML5 spezifiziert sind, ist die Validierung fest in sie eingebaut. Kein halbwegs aktueller Browser nutzt also die Validierung nicht – jedenfalls nicht, solange man sie nicht mit dem Attribut novalidate auf dem Formular-Element deaktiviert. Ansonsten gibt es noch die Möglichkeit, ausschließlich <input type="text"> und keins der neuen Validierungs-Attribute zu nutzen, aber dass die Validierungsmechanik zumindest nachschaut, ob sie aktiv werden muss, kann man nicht vorhindern. In HTML5 gehört Validierung fest zu Formularen dazu.

Was spricht gegen den Einsatz von HTML5 bei der Pflichtfeld-Validierung? Das ist recht simpel: sie funktioniert nicht in alten Browsern (IE < 10) und wenn JavaScript deaktiviert ist oder ausfällt, verwendet jeder Browser seine eigenen Styles um ungültige Felder anzuzeigen. Allerdings ist das auch das einzige Problem, funktionieren wird die Navigation auch ohne JS. Das hat sie auch jeder anderen denkbaren Lösung voraus und da man um eine serverseitige Validierung sowieso nicht herumkommt, spricht eigentlich nicht viel gegen den Einsatz von HTML5-Formularvalidierung.

Strukturierte Navigationen erlaubt?

Eine grundsätzliche Frage zum nav-Element: dürfen diese bei komplexen Navigationen auch Article- und Section-Elemente enthalten? Hier mal ein Beispiel, das meiner Problemstellung entspricht … darf man das?

Es sieht so aus als stünde dem zumindest formal nichts im Wege. Das Content Model des Nav-Elements (dritter Punkt in der grünen Box) erlaubt Sectioning Content, was grünes Licht für Article- und Section-Elemente bedeutet. Ganz am Ende des Abschnitts in den Spezifikationen heißt es beim letzten Beispiel sogar explizit A nav element doesn't have to contain a list, it can contain other kinds of content as well. Ob das dann auch sinnvoll und problemlos ist, ist eine andere Frage.

Ich würde sagen, dass man im Einzelfall testen sollte, wie Screenreader auf solche komplexen Konstruktionen reagieren und wie es allgemein mit der Usability aussieht (v.a. via Tastatur), aber laut Spezifikation spricht zumindest nichts dagegen, mit solchen Verschachtelungen zu experimentieren.

Weitere Fragen?

Eure Fragen zu HTML5, JavaScript und anderen Webtechnologien beantworte ich gerne! Einfach eine E-Mail schreiben oder Twitter bemühen und ein bisschen Geduld mit der Antwort haben. Ansonsten kann man mich natürlich auch mieten!