Webkrauts » Moderne Semantik

Hauptmenü

Suche

Newsfeeds

Trackbacks

Artikel

Moderne Semantik

HTML5 wird der neue Markup-Standard, daran gibt es mittlerweile keinen Zweifel mehr. Grund genug einmal zu schauen was eigentlich dahinter steckt.

Weshalb wurde HTML5 entwickelt?

Das Web hat sich seit 1999, als HTML4/XHTML1 entwickelt wurde, grundlegend verändert. Aus einem Web von statischen Dokumenten wurden hochkomplexe Applikationen, für die aber kaum semantisches Fundament vorhanden ist. Das soll sich in HTML5 ändern.

Die Entwicklung begann bei der WHATWG, einer Gruppe von Browserherstellern, die mit dem W3C-Prozess nicht einverstanden waren. Dort wurde der (zu vorigen (X)HTML-Versionen inkompatible) XHTML2-Standard entwickelt, der aber auf keinerlei Akzeptanz bei den Browserherstellern stieß. 2006 sah das W3C ein, dass HTML5 eine gute Sache ist und reaktivierte die alte HTML-Arbeitsgruppe. Beide Organisationen existieren heute nebeneinander und arbeiten an einer gemeinsamen Spezifikation, Editor Ian Hickson (Google) sammelt die Vorschläge und führt sie zusammen.

Was sind die Prinzipen und Ziele der HTML5-Entwicklung?

Unterstütze existierende Inhalte: Parser (nicht Autoren!) sollen mit alten, aber dennoch existierenden Techniken umgehen können, auch wenn sie nicht in HTML5 festgelegt sind. So werden bspw. fehlerhaft verschachtelte Elemente (<b>a<i>b</b>c</i>) genauso unterstützt wie Elemente, die nicht mehr zum Standard gehören (<u> etwa).
Graceful degradation (etwa: „Schrittweises Zurückfallen“): Wird eine Komponente in HTML5 nicht von einem Browser unterstützt, so darf das nicht dazu führen, dass die gesamte Webseite unzugänglich wird. Beispiel: Das (vorgeschlagene) irrelevant-Attribut kann per CSS emuliert werden: [irrelevant] {display:none;}
Das Rad nicht neu erfinden: Wenn es schon eine weit verbreitete und implementierte Technik gibt, dann sollte sie übernommen werden statt etwas komplett neues zu entwickeln. Beispiel: contenteditable="" (um Bereiche der Seite bearbeitbar zu machen) ist bereits in vielen Browsern vorhanden und wird daher übernommen.
Paving the Cowpaths (etwa: „Trampelpfade pflastern“): Wenn es schon weit verbreitete Techniken gibt, dann sollte in Erwägung gezogen werden diese zu nutzen. Beispiel: <br /> kommt oft in HTML statt <br> vor und es schadet niemandem, wenn man die Nutzung erlaubt.
Evolution statt Revolution: HTML5 entwickelt (X)HTML weiter und wirft altbekannte Grundsätze nicht weg. Das bedeutet, dass Webentwickler nichts komplett neues erlernen müssen, sondern nach und nach neue Features einbauen können. Das gilt natürlich auch für die Hersteller von Browsern.

Muss ich jetzt HTML statt XHTML schreiben?

Nein. HTML5 verfügt über beide Serialisationen (Schreibweisen), kann also sowohl als X(HT)ML als auch als HTML geschrieben und interpretiert werden. Wichtig ist: Beide verfügen nach dem Parsen über den selben DOM-Baum. Es wird also tendenziell einfacher JavaScripts für HTML und XHTML zu schreiben.

Der DOM-Baum von HTML4 und XHTML1-Dokumenten konnte zuvor trotz gleicher Schreibweise unterschiedlich sein. Bei einem HTML4-Dokument wird zum Beispiel bei folgender Tabelle ein <tbody> explizit in das DOM eingefügt, bei XHTML nicht:

<table><tr><td>Text</td></tr></table>

Das bedeutet, dass CSS wie table > tr > td in HTML4 keine Wirkung zeigt.

Zum anderen erlaubt HTML5 ausdrücklich die Nutzung der XML-Syntax für Elemente ohne End-Tag: <img … /> führt nicht mehr zu Validierungsfehlern, auch wenn man ein HTML-Dokument benutzt.

Wann wird HTML5 fertig?

„Fertig“ ist im aktuellen W3C-Prozess ein sehr dehnbarer Begriff. Ein (vorgeschlagener) Standard muss heute viele Tests überstehen und Bedingungen erfüllen, um vom W3C final abgesegnet werden. Für HTML5 wird dafür extra eine Testsuite erstellt, die dann auch noch von 2 Browsern (oder vom Marktführer) bestanden werden müssen. Dieser letzte Teil, der sich bis 2022 hinziehen könnte, ist aber in der Praxis für Webentwickler relativ uninteressant – wir nutzen ja auch CSS2.1, das sich seit Jahren in der Entwicklung befindet, weitgehend implementiert ist, aber eben noch keine W3C-Empfehlung ist. Trotzdem würde kein Webentwickler sagen CSS2.1 sei nicht „fertig“.

Die HTML5-Arbeitsgruppe im W3C bereitet gerade die Veröffentlichung eines ersten Last Call vor, die im Oktober erscheinen soll. HTML5 definiert dann praktisch eine Todo-Liste für die Browserhersteller.

Gerade in den letzten Wochen hat sich mit der Gründung der HTML5 Super Friends, unter der Führung von Jeffrey Zeldman, und der Einreichung ihrer Anregungen einiges an der Spezifikation geändert, was Autoren betrifft.

Sollte man HTML5 jetzt verwenden?

Das kommt auf das Projekt an. Es schadet nichts, gewohntes (X)HTML zu nutzen und den neuen Doctype drüber zu schreiben, doch es hat auch keine wirklichen Vorteile. Die neuen Elemente (<nav>, <article>, <section>) funktionieren in vielen Browsern noch nicht (IEs, Firefox 2) und haben dort wo sie funktionieren auch noch keine semantischere Bedeutung als divs. Will man alle Browser mit im Boot haben und die IEs auch ohne JavaScript unterstützen, so kommt man um Hilfkonstruktionen und mehrfachverschachtelte divs wohl nicht herum.

Für kleine, private Seiten, die nicht den Anspruch haben unter jeder Konfiguration gleich (gut) auszusehen, lohnt sich der Blick über den Tellerrand aber bereits, erst recht wenn man auch mit den neuen JavaScript-APIs spielen möchte. Für die alltägliche Arbeit sollte man aber vielleicht heute noch auf altbekannte Elemente setzen und eine Namenskonvention mit Klassen einführen, die HTML5-Elemente widerspiegelt.

Wie geht’s hier weiter?

In den nächsten zwei Wochen stellen euch einige unserer Autoren auf webkrauts.de die wichtigsten neuen Elemente im Detail vor – ausgehend vom aktuellen Entwurf. Es wird um die semantische Grundaufteilung einer Webseite gehen, um Elemente für Video- und Audiodateien, um Spielereien mit und um die neuen Möglichkeiten für das input-Element. Den Abschluss bildet ein Beispiel aus der Praxis: Wir nutzen HTML5 für ein Blog-Projekt.

Zum Autor

Eric Eggert glaubt an das offene und für jeden zugängliche Web. Deshalb setzt er sich im W3C mit dem neuen HTML5-Standard auseinander und hilft der BAD TF dabei gute Beispiele für Barrierefreie Webseiten zu entwickeln. Er bloggt (von Zeit zu Zeit) auf yatil.de.

Info:: Moderne Semantik ist Beitrag Nr. 587
Autor:: Eric Eggert am 21. September 2009 um 16:55
Kategorie:: Artikel, HTML5-Einführung

Kommentare

Bitte die Hausregeln beachten. Alle Kommentare werden auf werbliche Links/Nicknames geprüft und gegebenenfalls gelöscht.

1.

Eine Klasse-Idee, freue mich jetzt schon auf den Rest der Serie. Danke!

Kommentar von Peter Müller - 21. September 2009 um 22:10
2.

Hallo Eric,

vielen Dank für den optimistischen Ausblick. Ich freue mich schon sehr, einmal "von der Pike auf" mit zu erleben, wie Du eine semantisch sinnvolle Seite mit HTML5 skizzieren möchtest.
Da ich auch sehr an einem barrierefreien Netz interessiert bin freue ich mich schon sehr auf Deine angekündigten Werke.

Wir lesen uns!

philosapiens

Kommentar von philosapiens - 21. September 2009 um 22:13
3.

@philosapiens: Das sind natürlich nicht alle meine Artikel, sondern eine Gemeinschaftsproduktion von viele Webkrauts-Autoren. Ich habe das auch im Artikel noch einmal klar gestellt.

Kommentar von Eric Eggert - 21. September 2009 um 22:41
4.

Der Beitrag arbeitet Neues heraus und zeigt dennoch auch, mit welchem eigenen Anspruch HTML5 »in die Welt« entlassen wird. Insofern kann man nur sagen: Vielen Dank für die einordnenden Worte zum Thema.

Kommentar von Markus Sowada - 22. September 2009 um 08:54
5.

Ich freue mich schon sehr auf HTML5! Gerade Google und andere Firmen wollen ja HTML5 pushen.

Ich hoffe Microsoft wird so schnell wie möglich mitzieht!
Bei der "Marktmacht" die der IE noch hat, wäre es blöd wenn 50% der Leute keine HTML5 Seiten korrekt anschauen könnten.

Ich denke das könnte noch ein großes Problem werden!

Gruß aus Hamburg

Andy

Kommentar von Andy - 23. September 2009 um 09:59
6.

Das Rad nicht neu erfinden: Wenn es schon eine weit verbreitete und implementierte Technik gibt, dann sollte sie übernommen werden statt etwas komplett neues zu entwickeln.

Ist das die Policy der HTML-5-Entwickler? Wenn ja, dann halten sie sich leider nicht dran.

Beispiel 1: Es gibt RDFa [RDFa-SYNTAX, RDFa-PRIMER] und es gibt Mikroformate [microformats.org]. Aber was von anderen kommt, das ist den HTML-5-Entwicklern wohl nicht gut genug und sie erfinden das Rad neu: Microdata [HTML5], §5.

Beispiel 2: Es gibt eine Spezifikation für Ruby-Annotationen [RUBY]. Simple Ruby ist in dieser Form seit vielen Jahren schon im Internet Explorer implementiert. Dennoch denken die HTML-5-Entwickler gar nicht daran, die Ruby-Spezifikation so in HTML 5 zu übernehmen (von Complex Ruby mal ganz abgesehen). Stattdessen auch hier: Wir machen unseren eigenen Kram und schaffen das 'rb'-Element ab. [http://www.w3.org/TR/html5/text-level-semantics.html#the-ruby-element], §4.6.20 ff. Das ist IMHO bedauerlich und semantisch unsinnig.

Von

HTML5 entwickelt (X)HTML weiter und wirft altbekannte Grundsätze nicht weg.

kann kaum die Rede sein.

Gunnar

Kommentar von Gunnar Bittersmann - 23. September 2009 um 11:06
7.

@Gunnar Bittersmann:

Zu Beispiel 1:

Das stimmt so natürlich nicht. Microdata ist aus Microformats und RDFa zusammengeführt und versucht beiden Vorlagen gerecht zu werden. Microdata kann in RDFa umgewandelt werden, hat aber für den Autoren den entscheidenden Vorteil, dass es eine gewohnte Syntax ist. Zudem sind (momentan) XML-Namespaces in HTML5 nicht möglich, die RDFa zwingend voraussetzt.

Ich zitiere da gerne Matthias Pfefferle:

Microdata ist für mich die gelungene Weiterentwicklung der Microformats-Idee unter Berücksichtigung von RDFa und prinzipiell lassen sich auch beide Standards mit Microdata umsetzen.

Microdata ist zudem ein erster Entwurf, also eine Diskussionsgrundlage. Wie sehr diskutiert wird sieht man an dem HTML+RDFa-Draft, der ebenfalls veröffentlicht wurde. Es ist also noch viel Bewegung in dieser Frage.

Zu Beispiel 2:

Wie ich mir gerade versichern lies ist das rb implizit, da alles was nicht rt oder rp ist aber in einem ruby-Element steht Ruby-Base sein muss.

Es ist also simplifiziert aber vollständig kompatibel.

Kommentar von Eric Eggert - 23. September 2009 um 12:05
8.

Das Prinzip »Das Rad nicht neu zu erfinden« stimmt mit der Wirklichkeit gleichzeitig überein und auch nicht. Einerseits standardisiert man auch schlechte Techniken wie z.B. Microsoft Drag and Drop allein aus dem Grund, weil sie bereits da sind. Andererseits fährt man in verschiedener Hinsicht eine »Not invented here«-Politik und denkt sich z.B. neue Methoden zum Einbettung anderer Sprachen wie SVG, Ruby, RDF aus. Gut, das ist jeweils nötig, weil die HTML-Serialisierung keine Namensräume kennt. Eine (absichtliche, bewusste) Neuerfindung des Rades ist es trotzdem.

Kommentar von molily - 23. September 2009 um 14:23
9.

@molily

Auch wenn du das Gegenteil behauptest: Vorher gab es keine Möglichkeit diese ganzen Technologien in HTML einzubinden. HTML5 benutzt (angepasst) das was bereits in XML funktioniert und macht, dass es erstmals in HTML funktioniert. Wenn überhaupt wird hier ein Rad erfunden, aber sicher nicht neu erfunden.

Kommentar von Eric Eggert - 23. September 2009 um 14:32
10.

Ich habe nicht das Gegenteil behauptet. Das W3C hatte mit XHTML die Möglichkeit der Extensibility geschaffen, und damit das Rad »Einbettung von anderen Auszeichnungssprachen in das HTML-Vokabular« erfunden. (Klar, HTML 4 war dadurch nicht betroffen.) Jetzt wird dieses Rad nochmal erfunden, auf einer anderen Basis als XML. Was wie gesagt auch folgerichtig ist: Das »Gefährt«, das dadurch rollen soll, ist schließlich ein anderes.

Kommentar von molily - 24. September 2009 um 15:14
11.

Sehr angenehm zu lesen. Nun bin ich besser informiert was HTML5 angeht und freue mich auf die kommenden Artikel mit den befehlen.

Kommentar von Paul - 26. September 2009 um 04:36
12.

Ein guter Beitrag, der die Ziele nocheinmal herausstellt. Was mich jedoch an der Umsetzung stört: es wird wieder einmal (siehe XHTML 2) versucht, den großen Wurf zu landen, statt in kleineren Schritten zu standardisieren.

Und gerade die semantischen Elemente wie ARTICLE oder SECTION, die für den Browser im Prinzip nichts anderes sind als DIVs werden so ziemlich die letzten Elemente sein, die eingesetzt werden können – wenn sie dann noch im Entwurf sind und nicht durch Attribute ersetzt wurden.

Ich würde es begrüßen, wenn langsam mal ein (kleiner) gemeinsamer Nenner gefunden wird, in dem die vielen umstrittenen und unfertigen Elemente außen vor gelassen werden. Zum Beispiel ist für mich noch unklar, wie ich ein METER-Element mit CSS gestalten kann oder die Meldungen, die bei den neuen INPUT-Types ausgegeben werden. Nicht, dass am Ende so unterschiedliche und unvollständige Implementierungen herrauskommen wie bei HR oder FIELDSET, wo bei allen Browsern noch Nachholbedarf besteht.

Kommentar von Harald - 26. September 2009 um 18:45
13.

Wie ich mir gerade versichern lies ist das rb implizit, da alles was nicht rt oder rp ist aber in einem ruby-Element steht Ruby-Base sein muss.

Wenn den HTML-5-Machern das 'rb'-Element nicht gefällt, dann müssen sie halt ihren Einfluss im W3C (den sie offenbar mehr als gut ist haben) nutzen, damit die Ruby-Spezifikation geändert wird.

Es ist also simplifiziert aber vollständig kompatibel.

Nein, das ist es nicht. So wie es jetzt ist, muss für Ruby-Annotationen unterschiedliches Markup geschrieben werden: mit 'rb' in XML (incl. XHTML 1.1), ohne 'rb' in HTML 5. Das widerspricht jeder Vernunft.

Die HTML-5-Macher scheren sich einen Dreck um Vereinheitlichung von Webtechnologien, kochen stattdessen ihr eigenes Süppchen und erfinden auch noch das letzte Rädchen neu. Und das W3C segnet diesen Unsinn am Ende auch noch ab.

Kommentar von Gunnar Bittersmann - 12. Oktober 2009 um 12:28
14.

XML und HTML5 sind nicht kompatibel und müssen so und so konvertiert werden. Sich hier über die Arbeitsgruppe zu beschweren ist übrigens relativ sinnfrei, es ist sinnvoller sich direkt dort zu beschweren.

Kommentar von Eric Eggert - 12. Oktober 2009 um 13:23