Die nebenstehende Fragen-Artikel-Box wird so langsam zu lang. Für das nächste Redesign ist eine Einklapp-Funktionalität fest eingeplant, aber bis dahin müssen wir das Layout noch so ertragen wie es ist. Falls ihr euren Teil zur Verlängerung der Box betragen wollt, schickt auch ihr mir einfach eure Fragen zu HTML5 und Co.

HTML5-Elemente nicht benutzen – ein Fehler?

Ich habe noch nie wirklich HTML5-Elemente oder -Attribute verwendet. Ich benutzte eigentlich nur <div> mit data-*-Attributen und viel JavaScript. Mache ich etwas falsch?

Im Prinzip ist das durchaus ein Fehler. Wer keine HTML5-Elemente verwendet, verwendet andere Elemente, und über diese sagt die Spezifikation: Authors must not use elements [...] for purposes other than their intended semantic purpose. Und über das <div>-Element im Speziellen heißt es: Authors are strongly encouraged to view the div element as an element of last resort, for when no other element is suitable.

Ob man sich mit der Verletzung dieser Regeln wirklich einen wahrnehmbaren Nachteil einhandelt, steht freilich auf einem anderen Blatt. Jenseits aller semantischer Theorie besteht der Hauptunterschied zwischen den neuen semantischen HTML5-Elementen und dem guten alten <div> in den bei den neuen Elementen eingebauten Barrierefreiheits-Features. Ob man auf diese nun gesteigerten Wert legt oder nicht – es spricht nichts dagegen, diese einfach mitzunehmen und statt die <div>-Suppen mit ein paar <nav>- und <section>-Elementen zu dekorieren. Es kostet schließlich nichts.

Source Maps und mehrere Kompilier-Schritte

Source Maps sind schön und gut, aber was tun bei mehreren Kompilier-Schritten? Wenn ich z.B. mit Babel transpilierten Code erst durch Browserify und dann UglifyJS jagen möchte, bekomme ich doch keine Source Map mehr auf den Ausgangs-Quellcode mehr, oder?

Aber klar geht das! Die meisten der genannten Tools unterstützen Input-Source-Maps, UglifyJS z.B. über den Parameter --in-source-map. Diese Source Map wird dann als Ausgangslage für alle folgenden Transformationen genommen. Bei Inline-Maps (d.h. wenn die Source Map als Data-URL direkt in die JavaScript-Datei geschrieben wird) machen das die meisten Tools sogar automatisch. Und falls das mal nicht der Fall ist, kann man mittels Exorcist die Inline-Maps aus der Datei extrahieren und diese dann wiederum als Input für andere Tools nutzen.

Das <a>-Element in HTML5

Ist <ul><a href="#test"><li>Test</li></a></ul> gültiges HTML5? Es sieht nicht so aus, aber ich dachte bis gerade eben, man könnte in HTML5 um alles ein <a>-Element legen …

Nicht ganz: in HTML5 kann ein <a>-Element fast alles enthalten. Vor HTML5 waren HTML-Elemente in die zwei Kategorien Block-Elemente und Inline-Elemente eingeteilt und es galt die Regel: Inline-Elemente (wie <a>) dürfen keine Block-Elemente enthalten.

In HTML5 ist die Kategorisierung viel feinteiliger ausgefallen. Es gibt insgesamt sieben wichtige Sorten von Inhaltskategorien, wobei ein Element in mehrere Kategorien fallen kann. In welche Kategorie ein Element fällt, welche Elemente es enthalten kann und in welchen anderen Elementen es auftauchen darf, ist für das betroffene jeweils individuell Element definiert. Das <a>-Element darf beispielsweise überall auftauchen, wo sogenannter phrasing content erlaubt ist und es kann alles enthalten, was sein Elternelement enthalten darf – solange es sich nicht um interactive content, d.h. Inputs, andere Links etc. handelt.

Das <ul>-Element fällt in die Kategorie flow content. Es darf also auch in <a>-Elementen vorkommen, vorausgesetzt das Elternelements des <a>-Elements erlaubt flow content als Inhalt. Das war früher noch anders, denn da galten einfach <a> als Inline- und <ul> als Block-Element – die Kombination <a><ul></ul></a> war also nicht erlaubt. In HTML5 ist das hingegen kein Problem. Allerdings dürfen <ul> und auch <ol> weiterhin nur <li>-Elemente und Scripts als ihre Kindelemente haben.

Whitespace in HTML5

Definiert HTML5 irgendwo, wie der Browser mit Whitespace am Anfang oder Ende eines Elements umgehen soll? Sollten beispielsweise folgende Elemente immer gleich dargestellt werden (wobei „text“ hier für jedes Element mit Text darin stehen kann)?

text
[leerzeichen]text
text[leerzeichen]
[leerzeichen]text[leerzeichen]

Die Frage definiert HTML5 [kleines HTML-Syntax-Detail] … ist eigentlich immer mit Ja zu beantworten. HTML5 definiert den HTML-Parser bis ins kleinste Detail und dazu gehört auch die Verarbeitung von Whitespace.

Whitespace vor/nach/zwischen Elementen ist erlaubt (Inter-element whitespace) und führt zur Erzeugung von Textknoten mit nichts als eben dem Whitespace darin. Wenn wir im o.g. Beispiel mal <span>-Elemente als Beispiel-Non-Whitespace-Elemente hernehmen, sollte immer dieser DOM-Baum produziert werden:

  1. <span>A​</span>
  2. Textknoten "↵ " (Zeilenumbruch + führendes Leerzeichen)
  3. <span>B​</span>​
  4. Textknoten "↵" (Zeilenumbruch)
  5. <span>C​</span>​
  6. Textknoten " ↵ " (hinteres Leerzeichen + Zeilenumbruch + führendes Leerzeichen)
  7. <span>C​</span>​
  8. Textknoten " " (hinteres Leerzeichen)

Voraussetzung ist natürlich ein Browser mit ordentlichem HTML5-Parser an Bord.

Das Rendering dieser Whitespace-Textknoten ist durch die CSS-Eigenschaft white-space und nicht HTML5 definiert. Dort ist als Standardverhalten festgelegt, dass benachbarte Leerzeichen zusammengefasst bzw. alle bis auf eins auf eine Breite von 0 gequetscht werden. Mit anderen Werte für die white-space-Eigenschaft kann man das aber bequem den eigenen Wünschen anpassen.

Weitere Fragen?

All diese Fragen wurden mir per E-Mail oder Twitter gestellt und auch eure Fragen zu HTML(5), CSS(3), JavaScript und anderen Webtechnologien beantworte ich gerne! Einfach über einen der genannten Kanäle anschreiben oder gleich das komplette Erklärbären-Paket kommen lassen.