7.07.09
Das eigene Grab noch tiefer schaufeln.
XHTML 2 ist also jetzt offiziell tot. Schön, dass man sich seine Zukunft derartig verhunzen kann und nebenher noch jubelnd die Mistgabeln in die Höhe reckt.
HTML 5 wird als großer Fortschritt gefeiert. Das Entwicklerteam, das einst unabhängig vom W3C agierte und sich aus Browserherstelllern, Usabilityexperten und freien Webentwicklern zusammensetzt, arbeitet an der Spezifikation, die die Vorgänger HTML 4.01 und XHTML 1.0 ersetzen soll. Auch beim aktuellsten Working Draft vom 23. April 2009 wird darauf hingewiesen, dass die Spezifikation teilweise noch unausgereift ist.
Der Schwerpunkt der Arbeiten der HTML 5-Arbeitsgruppe liegt dabei auf der bereits erwähnten vollständigen Ablösung vorhergehender Standards. Während bei XHTML 2 eher der Ansatz einer kompletten Neuentwicklung besteht, versucht HTML 5 schon von vornherein auf Browserkompatibilität zu setzen. Stellenweise wird sogar schon davon geredet, HTML 5 produktiv einzusetzen; gewagt für eine im Entwurfstadium befindliche Spezifikation.
Ein gewichtiger Punkt auf der Liste der HTML 5-Features ist also die Abwärtskompatibilität. Die Entwürfe werden danach gerichtet, was mit heutigen Browsern teilweise schon möglich ist und was der zukünftigen Browergeneration nicht allzu viel Mühe machen wird.
Aufgrund dieser Zielsetzung ist es unmöglich, eine Spezifikation ohne Altlasten zu entwerfen. Die Toleranz von HTML 5 geht sogar so weit, dass das font-Element aufgenommen wird; mit der Begründung, dass WYSIWYG-Editoren ohne dieses nicht auskämen.
Derletzt sind wieder viele Webentwickler den Schritt zurück von XHTML 1.0 zu HTML 4.01 gegangen. Die Begründungen sind allesamt pragmatischer Natur; im Gegensatz zu den eher ideologischen Argumenten pro XHTML damals, als es in war, XML zu schreiben.
Leider fehlt mir bei all’ den Argumenten gegen XHTML die Rücksicht auf die Zukunft. Abwärtskompatibilität in einer Spezifikation, das mag, auf die Gegenwart und nahe Zukunft projeziert, sinnvoll erscheinen. Überlegt man sich aber, wo man eigentlich einmal hin möchte, erweisen sich diese Gedanken als äußerst kurzsichtig.
Um eines klarzustellen: Ich bin überzeugt, dass es nahezu unmöglich ist, eine gesunde, überlebensfähige Spezifikation für das Web zu entwerfen, die ohne jegliche Altlasten auskommt; zuviele Parteien haben ihre Griffel im Spiel. Deshalb bin ich mir auch bewusst, dass XHTML 2 nicht der heilige Gral gewesen wäre, denn auch diese Arbeitsgruppe nimmt genügend Relikte aus der Steinzeit mit. HTML 5 hingegen schafft neue Relikte, neue Altlasten, die die nächste Generation an Markup-Sprachen wieder auszubügeln haben wird.
Denn neben font, b, i und den ganzen anderen Elementen, die es aus unerklärlichen Gründen in die HTML 5-Entwürfe geschafft haben, gibt es neue Elemente, die neue Probleme schaffen werden.
Ich fange am besten ganz vorne an.
Der Doctype
Bis jetzt habe ich zum HTML 5-Doctype nur positive Stimmen lesen können. Das einzige Argument war dabei immer »Hui, den kann ich mir endlich mal merken!« Ich gebe zu, das ist wirklich ein pragmatisches Argument; blöd wird’s nur, wenn es einige Gegenargumente gibt, die weit mehr ins Gewicht fallen.
Warum gibt es überhaupt einen Doctype? Schaut man sich den von HTML 5 an, könnte man meinen, der Doctype wäre nur ein nötiges Übel; man muss es halt machen.
Der Doctype dient der Unterscheidung von Dokumententyp-Versionen. Aus dem HTML 5-Doctype geht jedoch nur hervor, dass es sich um HTML handelt, und nicht um welche Version. Wie werden die nächsten HTML-Generationen damit umgehen?
Aus den Diskussionen um die Form des Doctypes geht als Argument gegen ein <!doctype HTML5> hervor, dass diese Schreibweise gewisse derzeitig aktuelle Browser in den Quirks-Modus versetzt.
Wenn aber doch ganz offiziell verkündet wird, dass mit einer vollen Verbreitung von HTML 5 nicht bis 2022 zu rechnen sein wird, frage ich mich, warum man auf Browser achten sollte, die zu diesem Zeitpunkt fünfzehn bis zwanzig Jahre alt sein werden! Und das zu Ungunsten einer genauen Klassifizierung aller Dokumente, die auf diese Technologie setzen.
Weiter geht’s mit den neuen funktionalen Elementen. Anstatt eine langanhaltende Technologie zu schaffen, wird hier kurzfristige Erleichterung versprochen.
video und audio
Vor einiger Zeit wurde bekannt, dass Google, z.B. mit Youtube in Zukunft auf HTML 5 setzen wird, Begründung: das Video-Element ist klasse. Von Google hätte ich mir ein klein wenig mehr Weitsicht und Durchblick erwartet. »Endlich ist es möglich, auf Flash zu verzichten und trotzdem Videos in eine Website einzubetten«. Wir wissen hoffentlich alle, dass das lächerlich ist, denn man kann schon seit Ewigkeiten alle Arten von Multimedia-Elementen einbetten, object sei Dank.
Dass man im Browser Videos ohne Plugins abspielen möchte, ist ein teilweise verständlicher Wunsch. Dass man dazu eine neue Spezifikation benötigt, leuchtet mir allerdings nicht ein. Dadurch, dass HTML 5 explizit erwähnt, dass die Browser das »jetzt so machen«, heißt nicht, dass sie das nicht schon seit Urzeiten hätten tun könnten.
Genau dieses object-Element, das in XHTML 2 verbessert werden soll, indem beispielsweise die Attributnamen sinnvoller gestaltet werden, hat der Unterscheidung von audio, video und image einiges vorraus.
Multimedia beschränkt sich nämlich keinesfalls nur auf diese drei Gruppen. Was, wenn man in eine Website plötzlich Gerüche einbinden kann? Natürlich kann man auch in HTML 5 noch object einsetzen, aber das ist dann doch sehr heuchlerisch und inkonsistent.
Darüberhinaus muss man erwähnen, dass HTML 5 mit dem Video-Element keinesfalls das bietet, was es einst versprach. Seit kurzem ist bekannt dass es keinen einheitlichen Codec geben wird.
Die strukturierenden Elemente
In einer simplen Webseite steckt so viel potenzielle Semantik, da braucht man ein erweiterbares System, um alles abdecken zu können. XHTML 2 führt @role ein, ich denke, hier kann man von einfacher Erweiterbarkeit sprechen. Außerdem ist bekannt, dass das X in XHTML ermöglicht, über Namensräume andere XML-Dokumente einzubinden. Das könnten z.B. Vektorgrafiken (SVG), mathematische Ausdrücke (MathML) oder Multimedia-Informationen (SMIL) sein.
Was tut HTML 5? Aside, nav, header und footer decken einen Bruchteil der notwendigen semantischen Elemente ab.
Ich möchte dazu einfach mal Tobias Otte zitieren:
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.
Das ist der Punkt. XHTML 2 bietet diesen Mechanismus, HTML 5 nicht.
Schlusswort
Mit diesem Artikel habe ich mir wahrscheinlich auf beiden Seiten Feinde gemacht. Die trendhechelnde HTML-Fraktion wird mir aus naheliegenden Gründen Briefbomben en masse zusenden und die X-Parteien lynchen mich, weil ich bei weitem nicht alle Nachteile von HTML 5 und nicht alle Vorteile von XHTML 2 dargestellt habe.
Abschließend möchte ich sagen, dass ich die Entwicklung zwar verstehe, aber nicht gutheiße. Die zugrundeliegenden Konzepte beider Sprachen sind gut. Sauberer Rewrite gegen pragmatischen Realismus. Bei ersterem war das Problem der zu akademische Ansatz und bei zweitem wird das Problem die miese Ausführung sein.
Ich denke, dass eine Spezifikation nicht abwärtskompatibel sein sollte. Die bearbeitenden Programme sollten dies können, aber eine Spezifikation sollte man sauber schreiben, denn noch schlimmer, als dass man die Webdesigner mit Hacks frickeln lässt, ist es, die Hacks in eine Spezifikation einzubauen.
Einerseits kann ich schon verstehen, warum man keine Spezifikation ganz ohne Altlasten entwicklen kann. Andererseits schaufelt man sich mit so etwas wie HTML 5 nur noch tiefer ins Grab.
Kommentar verfassen
Meine Position
Ich bin ein junger Webdesigner und werde mich deshalb auch noch eine Weile mit Webstandards herumschlagen müssen. Zukunftssichere Technologien liegen mir deshalb besonders am Herzen. Das kann auch der Grund sein, warum ich mit HTML5 nicht so recht warm werde. Trotzdem versuche ich jede Entwicklung positiv zu sehen oder zumindest zum Positiven hin zu lenken.
Diskussionen sind mir besonders wichtig, ich lade deshalb jeden Leser herzlich ein, zu kommentieren und auch zu widersprechen.
Gastbeiträge
- Frequently Asked Questions
Gastbeitrag auf daswebdesignblog.de - Rendering von Vektorgrafiken: Die Mitte finden
Gastbeitrag auf Dr.Web - Rezension: Werkzeuge fürs Web
Gastbeitrag auf seo.de - Typographische Verrohung
Gastbeitrag auf Dr.Web