Arbeiten mit unbekannten Elementen

Warum HTML5 keine weiteren HTML-Versionen mehr vorsieht

Beim HTML5-typischen Dokumenttyp <!doctype html> haben Sie sich, falls Sie mit früheren HTML-Versionen und deren Konzepten vertraut sind, vielleicht gefragt, wie denn ein solcher Dokumenttyp mit künftigen Weiterentwicklungen von HTML vereinbar sein soll. Die Antwort ist: Es sind keine weiteren HTML-Versionen mehr vorgesehen. Die 5 in HTML5 ist eigentlich auch keine HTML-Version, sondern eher ein Erkennungsmerkmal für das HTML-Konzept jenseits der SGML-basierten Ära von HTML.

Doch was soll das bedeuten? Soll HTML eingedampft werden? Nein, im Gegenteil. HTML soll in Zukunft kontinuierlich weiterentwickelt werden. Aber eben nicht mehr in Form statischer Versionen, die ein ganzes Jahrzehnt brauchen, um überarbeitet zu werden. Stattdessen können jederzeit neue Sprachelemente hinzukommen. Dadurch wird künftig jederzeit zwischen der HTML-Spezifikation und dem, was in einzelnen Browsern davon implementiert ist, ein gewisser Unschärfebereich liegen. Das ist aber kein Grund zur Besorgnis. Denn es war in der Praxis noch nie anders. Noch nie hat jemals irgendein Browser den SGML-basierten HTML-Standard vollständig umgesetzt. HTML5 legalisiert diese Unschärfe lediglich, mit der Begründung, dass dadurch ein zwangloseres Weiterentwickeln von HTML und Browsern möglich sei.

Das HTML5-Handbuch gibt es eigentlich gar nicht

Letztlich kann durch den Ansatz von HTML5 auch das, was in einem HTML-Buch wie diesem steht, niemals ein vollständiges Abbild sein. Bücher über HTML werden ebenso kontinuierlich mit der Weiterentwicklung von HTML wachsen müssen, wie es die Browser-Software tun muss.

Allerdings muss bei der Fortentwicklung von HTML5 auch berücksichtigt werden, dass die WHATWG und das W3-Konsortium dabei ergänzende und unterschiedliche Rollen wahrnehmen. Während die WHATWG die laufende Weiterentwicklung besorgt, steht beim W3-Konsortium die Aufgabe im Vordergrund, stabile Zwischenversionen festzuschreiben.

Unbekannte semantische Elemente sind unbedenklich

HTML5 führt eine ganze Reihe neuer Elemente ein. Dabei muss man grundsätzlich zwischen zwei Sorten von Elementen unterscheiden:

  • Elemente, mit denen eine bestimmte Funktionalität verknüpft ist, die der interpretierende Client umsetzen oder erbringen muss. Beispiele solcher Elemente werden in späteren Buchabschnitten noch vorgestellt. Elemente dieser Sorte sind etwa video, audio, canvas oder command.
  • Elemente, die einfach eine sinnvolle Bedeutung haben, mit denen aber ansonsten keine spezielle Funktionalität verknüpft ist. Viele dieser neuen Elemente gehören zum Bereich der Textstrukturierung und wurden in diesem Buchabschnitt behandelt.

Während es bei Elementen der ersten Sorte sofort auffällt, wenn ein Browser sie nicht interpretiert, fällt es bei Elementen der zweiten Sorte kaum auf. Lediglich bei Elementen, die eine neue Zeile im Textfluss erzeugen sollen, fällt es auf, wenn der Browser das nicht umsetzt.

Im Klartext bedeutet das: es ist eigentlich gar nicht so wichtig, ob Ihr Browser oder die Browser der Anwender, die Ihre Seiten besuchen, HTML5-Elemente wie nav, aside, hgroup, figure usw. kennen oder nicht. Diese Elemente sind auch genaugenommen für Suchmaschinen interessanter als für Browser.

Eigene Elemente

Was mit noch neuen, unbekannten Elementen des HTML5-Standards funktioniert, funktioniert ebensogut mit beliebigen Eigenkreationen. Im HTML5-Zeitalter wird kein Validator mehr meckern, wenn in Ihrem HTML-Quelltext eine Auszeichnung wie <actor name="Tell">Durch diese hohle Gasse muß er kommen</actor> vorkommt. Letztlich geht es immer nur um die Frage: wer braucht das? Wenn Sie Gründe für ein eigenes semantisches Markup haben, etwa den, dass dies ein wertvoller Input für eine website-eigene Datenverarbeitung ist, dann spricht eigentlich nichts gegen solches Markup.

Das Internet-Explorer-Problem

Alle modernen Browser bis auf den Internet Explorer erzeugen von jedem unbekannten Element intern einen ganz normalen DOM-Elementknoten, auf den CSS-Selektoren anwendbar sind, oder auch DOM-Scripting. Beim Internet Explorer ist das leider nicht der Fall. Aus einem HTML-Code wie <nav><ul><li>HOME</li></ul></nav> erzeugt ein Internet Explorer, der die Elemente ul und li kennt, aber nicht das HTML5-Element nav, folgendes interne Abbild: <nav></nav><ul><li>HOME</li></ul></nav><//nav>. Ein unbekanntes Element wird also vom Internet Explorer nicht wie ein Element mit Inhalt, sondern stets nur wie ein Standalone-Element ohne Inhalt behandelt. Nicht einmal das End-Tag mit dem typischen Schrägstrich wird als solches erkannt, sondern lediglich als weiteres unbekanntes Standalone-Element aufgelöst. Es leuchtet ein, dass auf ein solches Element weder CSS-Angaben noch Scripting anwendbar sind. Das wäre eine bedauerliche Situation, denn es würde künftig über Jahre hinweg verhindern, dass Elemente wie header oder nav verwendet werden, weil man sie wegen des Microsoft-Browsers nicht ins CSS-basierte Website-Layout integrieren kann. Damit diese neuen Elemente eine Chance haben, sich durchzusetzen, sind Lösungen für das Internet-Explorer-Problem erforderlich.

Lösung: DOM-Objekte mit Scripting erzeugen

Es gibt eine relativ einfache Lösung, um das problematische Verhalten des Internet Explorers zu beseitigen. Alle unbekannten Elemente werden einfach zentral in einem Script einmalig als DOM-Objekte erzeugt. Anschließend behandelt der Internet Explorer die Elemente genauso wie die übrigen Browser. Nachfolgendes Beispiel-Script erzeugt Objekte aller neuen HTML5-Elemente, deren Zweck ausschließlich ein semantischer ist:

<script type="text/javascript">
document.createElement('article');
document.createElement('aside');
document.createElement('figure');
document.createElement('figcaption');
document.createElement('mark');
document.createElement('nav');
document.createElement('rp');
document.createElement('rt');
document.createElement('ruby');
document.createElement('section');
document.createElement('time');
</script>

Diesen Scriptbereich müssen Sie im HTML-Kopfbereich, also zwischen <head> und </head>, notieren. Alternativ können Sie den reinen JavaScript-Code, also ohne die Tags <script> und </script>, in einer separaten Textdatei mit der Endung .js speichern und diese im HTML-Kopfbereich mit <script type="text/javascript" src="dateiname.js"></script> einbinden. Die Lösung mit der separaten Datei hat den Vorteil, dass Sie diese Datei nur einmal erstellen müssen und dann in allen Webseiten einbinden können.

Die Lösung mit dem Script erfordert allerdings aktiviertes JavaScript im Internet Explorer (in den Einstellungen dort wird JavaScript als „Active Scripting“ bezeichnet). Zwar ist das die Voreinstellung, die auch von fast allen Anwendern benutzt wird. Doch wenn ein Anwender das Active Scripting aus irgendwelchen Gründen deaktiviert, wird die Lösung nicht mehr funktionieren, und als Folge davon würden CSS-basierte Layouts in Verbindung mit neuen Elementen zerhauen dargestellt.

Peter Kröner stellt in seinem Artikel HTML5 – Was geht heute schon, was geht nicht? Der große Überblick zusätzlich einen Lösungsansatz vor, der durch reine CSS-Selektorensyntax versucht das Problem im Internet Explorer zu umgehen. Dieser Lösungsansatz ist jedoch immer nur auf konkrete Inhalte anwendbar. Eine dritte Lösung wird in dem Artikel ebenfalls vorgestellt, die hier in etwas anderer Form ebenfalls vorgestellt werden soll. Notieren Sie ein unbekanntes Element als unmittelbares Kindelement eines anderen, bekannten Elements. Beispiele: <div class="nav"><nav><ul><li>HOME</li></ul>/nav></div> oder <p>Text <span class="time"><time>23.08.2011</time></span> Text </p>. Das äußere, bekannte Element bekommt dabei eine Klasse zugewiesen. Der Klassenname ist frei wählbar. Sinnvollerweise bietet sich der Name des inneren, unbekannten Elements an. Solche Elemente können Sie nun in einem separaten Stylesheet, das nur der Internet Explorer interpretiert, mit CSS formatieren. Ein solches Stylesheet können Sie mit Hilfe eines Conditional Comments einbinden. So erzielen Sie letztlich die gleichen Formate wie in anderen Browsern, mit dem Unterschied, dass es im Internet Explorer in Wirklichkeit nicht das nav-Element ist, das formatiert ist, sondern das umschließende div-Element.

 


Korrekturen, Hinweise und Ergänzungen
Bitte scheut euch nicht und meldet, was auf dieser Seite sachlich falsch oder irreführend ist, was ergänzt werden sollte, was fehlt usw. Dazu bitte oben aus dem Menü Seite den Eintrag Diskutieren wählen. Es ist keine Anmeldung erforderlich, um Anmerkungen zu posten. Unpassende Postings, Spam usw. werden allerdings kommentarlos entfernt.

Sofern nicht anders angegeben, steht der Inhalt dieser Seite unter Lizenz Creative Commons Attribution-ShareAlike 3.0 License