Semantik in HTML 5
Dieser Artikel ist eine freie Übersetzung von Semantics in HTML 5, geschrieben im Januar 2009 von John Allsopp für A List Apart.
Ich werde nun eine mutige Vorhersage machen. Lange nachdem wir nicht mehr auf dieser Erde verweilen wird HTML immer noch da sein. Nicht nur in Milliarden archivierter Seiten unserer Ära, sondern als ein lebendiges, atmendes Wesen. Zu viel Anstrengungen, Energie und Investitionen wurden in die Entwicklung von Webtools, Protokollen und Plattformen gesteckt um es so leicht aufzugeben.
Lasst uns über unsere Verantwortung nachdenken. Durch einen Zufall der Geschichte sind wir mit der Entwicklung eines der wichtigsten Kommunikationswerkzeuge unserer Zivilisation für die nächsten Jahrzehnte verbunden. Also, wenn wir, ob träumerisch oder ernsthaft, darüber nachdenken HTML zu verbessern müssen wir verstehen wie weitreichend die Verzweigungen unserer heutigen Entscheidungen sein könnten.
HTML 5, das W3C verdoppelte kürzlich die Anstrengungen um die nächste Generation von HTML in Form zu bringen, hat im letzten Jahr erheblich an Schwung gewonnen. Es ist ein gewaltiges Projekt, es umfasst nicht einfach nur die Struktur von HTML sondern auch das DOM, Algorithmen für Resourcenfetching, Mediainhalte, 2D Zeichnungen, Datentemplating, clientseitige Datenspeicherung, Modelle für Syntaxanalyse, Ausnahmebehandlung, Sicherheit und Pageloading und vieles mehr.
Es gibt außerdem Verbesserungen der Struktur, Syntax und Semantik von denen einige in „A Preview of HTML 5.“ von Lachlan Hunt gezeigt werden.
Aber in diesem Artikel wollen wir uns auf die Semantik konzentrieren. Sie ist etwas was mich seit vielen Jahren beschäftigt und sie ist meiner Meinung nach fundamental wichtig für die Zukunft von HTML.
Die BBC kündigte vor kurzem an, dass sie, aufgrund von Zugänglich- und Nutzbarkeitsüberschneidungen bei dem abbr
-design-pattern, das hCalender Microformat aus ihren Programmübersichten entfernen wird. Dies zeigt das wir ohne jeden Zweifel die Semantik von HTML weit weg von dem was wir eigentlich wollten und auch weit weg von dem was eigentlich mit der Sprache möglich ist gebracht haben. Wir haben einfach die Kontrolle über die HTML Elemente und Attribute mit denen wir semantische Dokumente auszeichnen verloren. Wenn wir weiterhin so geschickt mit dem existierenden Konstrukt umgehen werden noch mehr Probleme wie dieses entstehen. Aber HTML leidet als semantische Auszeichnungssprache unter einem grundlegenden Mangel — die Semantik ist fest und nicht austauschbar.
Dies ist nicht einfach nur ein theoretisches Problem. Hunderttausende Entwickler nutzen das class
und id
Attribut um die Semantik Ihrer Dokumente zu verbessern. (Sie nutzen sie auch als „Haken“ für das Styling mit CSS aber das ist eine andere Baustelle.) Fast ausnahmslos verwenden diese Entwickler zum Inhalt passende Begriffe — diese sind, anstatt Werte von existierenden Schemas zu nutzten, selbst ausgedacht. Es ist bestenfalls pseudosemantisches Markup.
Viele Seiten im Web nutzen Microformate um mehr strukturierte Semantik einzusetzen als eigentlich in HTMLs dürftigen Satz von Elementen und Attributen vorhanden ist. In diesem Fall sind die Werte die für das class
Attribut genutzt werden festgelegte Begriffe, manchmal übernommen aus vorhandenen Standards wie vCard, machmal sind es neu erdachte Begriffe für die vorher kein stabiler Standard vorhanden war (wie im Fall von hReview).
Erweiterbare Semantik
Es ist ein sehr reales Problem welches gelöst werden muss. Wir brauchen einen Mechanismus in HTML welcher Entwicklern die Möglichkeit geben muss klar und unzweideutig bessere und aussagekräftigere Semantik, nicht Pseudosemantik, in ihr Markup zu integrieren. Die ist vielleicht das dringlichste Ziel für das HTML 5 Projekt.
Aber es ist nicht so einfach einen neuen Mechanismus zu entwickeln: Es gibt bedeutende Einschränkungen für jede Lösung. Die vielleicht größte ist die Rückwärtskompatibilität. Die Lösung kann nicht Millionen an vorhandene und auch in den kommenden Jahren genutzten Seiten unbenutzbar machen. Jede Lösung die nicht rückwärtskompatibel ist wird aus Angst vor dem Ausschließen von Nutzern nicht weit genug von den Entwicklern angenommen. Sie würde schnell untergehen.
Die Lösung muss aber auch vorwärtskompatibel sein. Nicht in dem Sinne das sie in zukünftigen Browsern funktionieren muss — das liegt in der Verantwortung der Browserentwickler — aber sie muss erweiterbar sein. Wir können nicht erwarten das eine einzige Lösung die wir jetzt entwickeln alle vorstellbaren und unvorstellbaren semantischen Notwendigkeiten der Zukunft abdeckt. Wir können eine Lösung entwickeln die erweiterbar ist um zukünftigen Anforderungen entgegen zu kommen.
Diese zwei Aufgaben zusammen sind eine große Herausforderung. Aber im Kontext einer Sprache deren nächste große Überarbeitung in einem Jahrzehnt kommt und deren Einfluss auf eine globale Plattform für Kommunikation überragend ist muss diese Herausforderung gelöst werden.
Also wie löst HTML 5 dieses Problem? HTML 5 führt neue Elemente ein. Einige davon sind das was ich als „strukturell bedingt“ bezeichne — section
, nav
, aside
, header
, und footer
. Das dialog
Element ist eine Art Content-Element in Anlehnung an blockquote
. Es gibt außerdem einige Datenelemente wie zum Beispiel meter
und das time
Element welches ein Datum und/oder eine Zeit markiert.
Auch wenn die Elemente nützlich sein können und auch schon einiges Interesse auf sich gezogen haben, lösen sie wirklich die Probleme die wir identifiziert haben, besonders in Anbetracht der Vor- und Rückwertskompatiblität?
Lasst uns jede Bedingung einzeln betrachten.
Rückwärtskompatibilität
Wie gehen gegenwärtige Browser mit neuen Elementen wie dem section
Element um? Gut, die aktuellen Versionen von Safari, Opera, Mozilla, und auch der IE7 wird die Seite wie folgt rendern.
<h1>Top Level Heading</h1>
<section>
<h1>Second Level Heading</h1>
<p>this is text in a section element</p>
<section>
<h1>Third Level Heading</h1>
</section>
</section>
Sieht nach einem guten Start aus. Aber wenn wir versuchen zu stylen, zum Beispiel das section
Elemente mit diesem CSS:
section {color: red}
können zwar die meisten der oben erwähnten Browsers das Element stylen aber der IE7 (und somit vermutlich auch der 6) können es nicht.
Also haben wir ein ernsthaftes Problem mit der Rückwärtskompatibilität in 75% der momentan genutzten Browser. Wenn wir uns die Halbwertszeit des Internet Explorers ansehen können wir voraussagen das auch noch in einigen Jahren die meisten Nutzer den IE6 oder den IE7 nutzen werden.
Wenn HTML 5 diese neuen Elemente einführt, wie hoch ist die Wahrscheinlich das die Mehrheit der Entwickler sie auch nutzen das Wissen vorausgesetzt das sie im wesentlichen inkompatibel mit der Mehrheit der genutzten Browser sind?
Wenn wir nach einer alternativen Lösung für das CSS Problem schauen, das Setzen eines class
Attributs für die section
Elemente um sie dann über die Klasse zu stylen funktioniert es unglücklicherweise auch nicht im IE. Es gibt vielleicht einige Workarounds aber diese stellen auch keine praktikable Lösung da.
Weiter geht es mit der Vorwärtskompatibilität, der zweiten Bedingung.
Vorwärtskompatibilität
Starten wir mit der Frage: „Warum erfinden wir diese neuen Elemente?“ Eine begründete Antwort könnte sein: „Weil HTML nicht semantisch genug ist und durch die neuen Elemente steigern wir die Semantik“ — das kann nicht falsch sein, oder?
Durch das Hinzufügen dieser Elemente zeigen wir das HTML mehr semantische Fähigkeiten braucht. Aber nur in einem engen Anwendungsbereich. Egal wie viele Elemente wir aussieben wir werden immer denken das es nicht ausreicht. Also, wir können so viele Elemente hinzufügen wie wir wollen, es wird das Problem nicht lösen. Wir brauchen nicht spezielle Ausdrücke zu den Begriffen von HTML hinzufügen, wir müssen eine Mechanismus einbauen der es uns erlaubt einem Dokument so viel semantische Fülle zu geben wie es braucht. Wir müssen HTML erweiterbar machen. HTML 5 enthält keinen Mechanismus für Erweiterbarkeit.
HTML 5 implementiert Dinge die in einem großen Prozentsatz der aktuellen Browser nicht funktionieren und uns somit überhaupt nicht erlaubt wirklich die Semantik zu erweitern.
Verschiedene Fragen betreffend dieser neuen Elemente bleiben über. Woher kommen die Namen? Wie wurde es entschieden das es ein Element für die Navigation gibt das "nav" genannt wird? Warum sollen die selbe Bedingung auch auf andere Navigationen zutreffen?
Warum keine Begriffe aus existierenden Systemen, so wie Docbook, übernehmen? Seine Dokumentstruktur ist viel reichhaltiger und es wurde über viele Jahre von Puplishing-Experten entwickelt. Dies ist kein Argument zugunsten von Docbook speziell: Der Punkt ist das die extrem wichtige Aufgabe die Semantik von HTML zu erweitern sich nicht plötzlich stellt weshalb sich ein Blick auf die besten Arbeiten der letzten 30 Jahre lohnt. (Ursprünglich begann die Arbeit an GML in den frühen Siebzigern).
Einige Gedanken über eine Lösung
So, ich kritisiere die gegenwärtigen Bemühungen, habe ich auch eine praktische Lösung für das Problem? Nun, ich habe zumindest einen Anfang.
Wenn das Hinzufügen neuer Elemente in HTML nicht in Frage kommt, zumindest nicht innerhalb dieser Diskussion, sind logischerweise die Attribute der Bereich von HTML auf den wir uns konzentrieren sollten. Für fast ein Jahrzehnt haben wir class
und id
Attribute zur Erweiterung von HTML genutzt. Ein Großteil der Entwickler sind den Umgang mit diesen gewohnt. Das Microformat Projekt zeigt das die existierenden Attribute von HTML nicht ausreichen um die Semantik von HTML zu erweitern. Also, wenn wir Attribute zur Lösung dieses Problems nutzen möchten, müssen wir ein oder mehr neue Attribute hervorbringen. Bevor wir darauf eingehen wie das funktioniert ist es nur fair wenn wir für diesen Vorschlag die gleichen Anforderungen stellen die wir auch an die neuen HTML 5 Elemente stellen. Das Wichtigste, ist die Einführung neuer Attribute rückwärtskompatibel? Und wenn sie es ist, bietet sie einen funktionierenden Mechanismus um die Semantik zu erweitern?
Erfinden wir ein neues Attribut. Ich nenne es „structure,“ aber der genaue Name ist nicht von Bedeutung. Wir können es so nutzen:
<div structure="header">
Schauen wir wie unsere Browser damit umgehen.
Natürlich werden alle Browser diese Elemente mit CSS gestalten.
div {color: red}
Aber wie ist es hiermit?
div[structure] {font-weight: bold}
Beinahe alle Browser, einschließlich des IE7, stylen das div
tatsächlich obwohl das structure
Attribut überhaupt nicht existiert! Leider verlässt uns unser Glück nun, der IE6 tut es nicht. Aber wir können das Attribut in HTML nutzen und alle Browser können damit umgehen. Wir können sogar mit CSS unser HTML für alle modernen Browser stylen. Und wenn wir einen Workaround für alte Browser brauchen können wir ein class
Attribut anfügen und darüber stylen. Vergleicht das mit der HTML 5 Lösung welche neue Elemente hinzufügt die nicht im Internet Explorer 6 oder 7 gestyled werden können und ihr seht das dies eine definitiv rückwärtskompatiblere Lösung ist.
Erweiterbarkeit der Attribute
Anstelle von neuen Elementen sollte HTML 5 einige neue Attribute hinzufügen. Jedes dieser Attribute würde Bezug zu einer bestimmten semantischen Kategorie oder einem Typ haben. Zum Beispiel, wie ich in einem anderen Artikel detailliert beschreibe, umfasst HTML strukturelle Semantik, rhetorische Semantik, funktionsbezogene Semantik (übernommen von XHTML) und andere Klassen oder Kategorien.
Diese neuen Attribute können genau so genutzt werden wie das class
Attribut: Um dem Element Angaben hinzuzufügen die es beschreiben oder ergänzendes zum Inhalt enthalten.
Dies ist nicht unähnlich dem role
Attribut von XHTML aber anstatt nur ein Attribut „Behältnis“ zu haben sollten wir die verschiedenen semantischen Typen separieren.
Das XHTML role
Attribut arbeitet zum Beispiel so:
<ul role="navigation sitemap">
<li href="downloads">Downloads</li>
<li href="docs">Documentation</li>
<li href="news">News</li>
</ul>
Die Werte des role
Attributs sind eine durch Leerzeichen getrennte Liste aus den vorgegebenen Begriffen.
Warum nicht das role
Attribut übernehmen so wie es ist? Nun, es gibt noch andere Arten von Semantik für die die Bezeichnung „role“ nicht passt. Zum Beispiel:
<p rhetoric="irony">He’s a fantastic person.</p>
Dies zeigt einen theoretischen Typ von Semantik — „rhetoric“ — welcher eingesetzt werden könnte um die rhetorische Beschaffenheit zu beschreiben. Dieses Element hat natürlich nicht die Aufgabe „Ironie“ in dem Dokument, vielmehr ist der Inhalt des Elements ironisch.
Hier ein anderes Beispiel. Es zeigt sich immer mehr das HTML die Möglichkeit fehlt um maschinenlesbare Angaben an für Menschen optimierte Inhalte anzufügen, wie z.B. bei einer Zeitangabe. Dies ist das Hauptproblem das die BBC wie bereits erwähnt mit dem hCalendar Microformat hatte. Während <span role="2009-05-01">May Day next year</span>
nicht wirklich sinngemäß ist, ist <span equivalent="2009-05-01">May Day next year</span>
durchaus sinnvoll.
Auch hier ist es egal ob wir „equivalent“ nutzen oder eine andere Bezeichnung. Wichtig zu wissen ist nur das es nicht so simpel ist wie das class
Attribut oder das role
Attribut als Einheitsbehältnis für alle semantischen Informationen zu nutzen. Für eine sauber erweiterbare Lösung die Rückwärtskompatiblität und genügend Flexibilität gewährleistet wäre eine Lösung in die oben beschriebene Richtung zumindest in Betracht zu ziehen.
Ich habe diesen Absatz mit „Einige Gedanken über eine Lösung“ betitelt weil der wichtige Teil der Arbeit das Entwickeln einer durchführbaren Lösung ist. Offene Fragen sind folgende.
- Wie viele unterschiedliche Semantik-Attribute soll es geben? Sollen diese Kategorien erweiterbar sein und wenn ja, wie?
- Wie werden die Begriffe festgelegt?
- Sollen wir die Werte die wir brauchen einfach erfinden, so wie die Entwickler es bei den
class
Werten tun oder sollen alle Werte in einer standardisierten Spezifikation festgelegt werden? Oder soll es eine Technik geben um, über eine Art Profil, Begriffe zu erfinden (und hoffentlich auch zu teilen)? - Wenn ein Konflikt zwischen zwei Begriffen auftritt, beispielsweise wenn zwei identische Ausdrücke durch zwei verschiedene Begriffe definiert werden, wie wird er gelöst?
- Brauchen wir eine Form von Namensraum oder existiert eine andere Technik?
Anstelle von einer gehetzter Beantwortung dieser Fragen werfe ich sie auf um die Aufgaben die erfüllt werden müssen hervorzuheben. Und um einen Dialog zu starten. Die Verzweigungen und der Umfang der Entscheidungen die für HTML 5 getroffen werden müssen sind zu groß um sie ohne tiefgreifende Kenntnisse über Linguistik, Semantik, Semiotik und verwandte Bereiche zu treffen.
Hoffentlich ist es, wenn schon sonst nichts, klar, dass einfaches Erfinden neuer Elemente die Semantik von HTML nicht erweitert.
Lasst uns diese Entscheidungen nicht leichtfertig treffen — mit dem Klimawandel haben wir unsere Enkel schon genug belastet. Lasst uns ihnen das bestmögliche HTML hinterlassen.