1263589488|%d.%m.%Y
HTML hat sich allen Totsagungen der Vergangenheit zum Trotz als Basissprache für Webseiten gehalten. Und nun redet alles von HTML 5, dem neuen HTML-Standard. Erstaunliche Dinge werden damit möglich, vom direkten, flash-losen Abspielen von Video- und Audio-Ressourcen im Browser bis hin zum clientseitigen Speichern von Daten. Weniger reflektiert wird darüber, dass „HTML 5“ ein Widerspruch in sich ist. Denn HTML 5 bedeutet auch das Ende aller HTML-Versionen.
Wie Heise berichtet, träumen die führenden Köpfe der WHATWG im Rausch der Zielgeraden von HTML 5 bereits von künftigen HTML-Erweiterungen. Von „HTML 6“, wie der Heise-Artikel in Anführungszeichen anmerkt. Es wird jedoch wahrscheinlich kein HTML 6 mehr geben. Nicht, weil HTML am Ende ist, sondern weil das Konzept der Versionierung von HTML am Ende angelangt ist.
Im neuen Minimal-Doctype von HTML 5 (<!DOCTYPE html>), der dem Browser gerade noch mitteilt, dass die nachfolgenden Zeilen ein HTML-Dokument darstellen, gibt es keine Angabe zur Version mehr. Auch das ursprünglich mal diskutierte version-Attribut im einleitenden <html>-Tag ist entfallen. Browsers will treat all versions of HTML as HTML 5, so die neue Direktive. Da es bei dem, worauf nun alles wartet, nämlich HTML 5, nicht bleiben wird, gilt aber auch: Browsers will also treat HTML 5 and everything beyond simply as HTML.
Damit trägt man einfach der Realität Rechnung, dass wohl kein je entwickelter HTML-Parser jemals irgendeine HTML-Version vollständig implementiert hat. Jeder HTML-Parser implementiert einen jeweils realisierbaren Entwicklungsstand von HTML, und HTML entwickelt sich unterdessen weiter. Lange hat man für diese Einsicht benötigt, und vor einigen Jahren wäre man mit solchen Gedanken vermutlich von Experten als dummer Dilettant abgekanzelt worden.
Das 100%-Ideal der Versionserfüllung ist also ausgeträumt. Gewonnen hat man damit jedoch das unverkrampfte parallele Weiterwachsen von Sprache und Implementierungen. Bei Implementierungen, die sich auf der Höhe der Zeit befinden, wird es allenfalls einige Unschärfen in den Randbereichen geben. Implementierungen, die einfach veraltet sind und nicht mehr weiterentwickelt werden, werden irgendwann eben einfach unbrauchbar.
Vor einigen Jahren wäre eine solche Praxis allerdings noch gar nicht möglich gewesen. Genauer, sie wäre von den Browser-Entwicklern als Freibrief für muntere Eigenentwicklungen missverstanden worden. Die Browserkriege der 90er Jahre mit ihrem wilden Feature-Wettrüsten jenseits aller Standards wären wieder ausgebrochen und hätten im Webentwicklungsbereich für heilloses Chaos und für schlimme ideologische Radikalisierungen gesorgt. Die neue Realität von HTML 5 alias nur-noch-HTML ist deshalb auch ein Sieg der geläuterten Vernunft. Die Kinder respektive die Browser und die Unternehmen, die sie entwickeln, haben gelernt, sich freiwillig an die Regeln der Standards zu halten. Auch ein strenges, wild regulierendes und paternalistisches W3-Konsortium wird angesichts dieser erwachsen entspannten Haltung aller Beteiligten allmählich überflüssig.
Als interessante, weiterführende Lektüre zu diesem Thema sei das Dokument Architectural Considerations for Language Versioning for the Web empfohlen. Bleibt nur noch zu hinzuzufügen, dass wir definitiv kein SELFHTML 9 brauchen, wohl aber SELFHTML ;-)
Dann starte ich die Kommentare mal selber. Muss mich ja nicht an alle Regeln der guten Bloggerei halten. Habe gerade von XMLArbyter den Hinweis erhalten, dass man HTML5 mittlerweile nur noch ohne Leerzeichen zwischen "HTML" und "5" schreibt. Vorschrift ist Vorschrift! Naja, aber gehts nicht gerade darum? Also ich habe beschlossen, künftig nur noch "HTML" zu schreiben ;-)
Du hättest unsere private Kommunikation hier nicht breittreten müssen. "Vorschrift ist Vorschrift!" stammt übrigens nicht von mir, könnte aber so verstanden werden. Der Hinweis kommt aus meiner eigenen Beschäftigung mit HTML5 (Vortragsmaterial). War also nicht "bürokratisch" gemeint. Ansonsten halte ich Versionsnummern durchaus für sinnvoll, denn wie sollte man sich sonst konkret über die inhaltlichen Dinge ausdrücken? Ich würde das am ehesten an einer DTD oder einem XML-Schema festmachen, aber das ist ja gerade nicht gewollt.
Hallo Thomas,
tut mir leid, hast Recht, ich hätte in dem Fall zumindest deinen Namen aus dem Spiel lassen sollen! Du hast es wahrscheinlich einfach als kleinen Fehlerhinweis gemeint, den man nicht gleich öffentlich machen muss, und ich empfand den Hinweis gar nicht als Fehlerhinweis, sondern eher gedanklich so anregend, dass ich gleich dazu meinen Senf ablassen musste.
Ich halte definierte Stände bei Standard-Dokumenten ebenfalls für unverzichtbar. Bin bei früheren SELFHTML-Versionen ja selber mehrfach Opfer davon geworden, dass ich Sachen auf Basis von irgendwelchen WDs beschrieben habe und die Beschreibungen plötzlich nicht mehr stimmten, nur weil die WD gerade mal überarbeitet worden war. Wenn es anstelle von definierten Ständen nur noch solche Drafts gäbe, die einfach von heute auf morgen ein neues Datum und geänderte Inhalte haben, dann wären die Standards keinen Deut mehr wert.
Aber ich finde es auch richtig, wenn man aus dem Umstand, dass die Fachwelt nur kopfschüttelnd schmunzelt über die Versionsverrenkungen (erst XHTML 1.1 und 2.0 gleichzeitig, dann alles fix mal alles auf Version 5 hoch, auch XHTML und DOM usw.), und jetzt noch die Ankündigung, dass nach HTML5 die HTML-Versionenzählung aufhören soll. Sollen sie sich mal was einfallen lassen. Vielleicht so was Nettes wie "HTML Summer 10" oder "CSS Autumn 11". Quartalsdenken versteht jeder in der Wirtschaft, und wenn es alle paar Monate ein paar Verbesserungen im Standard gäbe, könnten Browser-Anbieter im Rahmen ihrer Entwicklung darauf reagieren. Computerbuchverlage würden frohlocken, weil sie jedes Quartal neue Fachbücher rausbringen könnten, und und und … :-)
viele Grüße
Stefan Münz
»HTML5« ist weniger eine Vorschrift als eine Sprachkonvention, um Missverständnisse wie »nach HTML 5 kommt HTML 6« zu vermeiden - auch wenn das beim Heise-Newsticker nicht gefruchtet hat. ;-)
Dass nun das Ende der Geschichte erreicht ist und sich die Vernunft verwirklicht hat, wage ich zu bezweifeln. Selbst wenn sich alle Browserhersteller Standards verschrieben haben, gibt es »muntere Eigenentwicklungen« immer noch reichlich und es wird sie auch weiterhin geben. Z.B. versucht Apple seine ursprünglich proprietären Erfindungen beim W3C zu veröffentlichen (z.B. CSS Transformation, Transition, Animation sowie Canvas und Web SQL Database). An der unilateralen Erfindung kann nachträglich nur wenig gerüttelt werden. Die Maxime lautet, wie auch schon 1993, »shipping code wins« (Mark Pilgrim).
Diese Techniken sind eigentlich alle sehr brauchbar, deshalb will ich mich gar nicht darüber beschweren, dass Apple sie einst eigenmächtig in die Welt gesetzt hat. Die anderen Browserhersteller haben diese Techniken aus praktischen Gründen 1:1 übernommen - im Falle von CSS mit Hersteller-Präfixen, solange sie noch nicht standardisiert sind. Daher müssen wir vorübergehend solches CSS schreiben, um in allen Browsern dasselbe zu erreichen: -webkit-eigenschaft: wert; -moz-eigenschaft: wert; -o-eigenschaft: wert; -ms-eigenschaft: wert; usw.
Einen Sieg der Vernunft würde ich das noch nicht bezeichnen. Die Browserhersteller haben lediglich eine grundsätzliche Bereitschaft gewonnen, Techniken zu standardisieren. Und es gibt jemanden, der hinterher aufräumt: Die WHATWG bzw. das W3C, die brauchbare Eigenentwicklungen kurzerhand zum Standard verbacken. Dieser Pragmatismus ist sicher zu begrüßen, denn er bringt für Webautoren einen enormen technischen Fortschritt. Zu ergänzen wäre, dass damit - nach wie vor - heftige Konflikte einhergehen, gerade in der jüngsten Zeit (siehe Liste mit Artikeln und Äußerungen hier und HTML5 is a (Beautiful) Mess). Wir sind mitten in einem Machtkampf zwischen WHATWG und W3C.
Die WHATWG vertritt die arrogante Haltung »wenn es nicht anders geht, dann mit dem W3C, andernfalls ohne«. Kritik an konkretem Verfahrensweisen des W3C mag ihre Berechtigung haben, aber es wäre kurzsichtig, die Überflüssigkeit des W3Cs zu konstatieren. Das W3C ist immer noch der Versuch, verschiedene Interessensvertreter der IT-Industrie, unabhängige Experten sowie Wissenschaft und Forschung zusammenzubringen. Die WHATWG hingegen besteht aus wenigen Leuten, die lediglich die Browserhersteller Google, Opera, Apple und Mozilla vertreten. Insofern ist der Anspruch der WHATWG kritikwürdig, für alle sprechen zu können und die Zukunft des Webs alleine bestimmen zu können. Dass dieser homogenen Gruppe die W3C HTML WG gegenübersteht mit starren, aber »demokratischeren« Verfahren, die z.B. jedem eine Einspruchsmöglichkeit gewähren und die Standards auf Qualitäten wie Barrierefreiheit verpflichten, ist erst einmal sinnvoll und bitter nötig, damit eine brauchbare Spezifikation herauskommt. Selbst die in der WHATWG organisierten Browserhersteller wissen, dass es gänzlich ohne eine Instanz wie das W3C nicht geht.
Hallo Molily,
erst mal danke für die vielen Informationen in deinem Beitrag!
Was ich ehrlich gesagt als gar nicht so negativ betrachte, solange es nicht, wie in den Anfangsjahren des Web, dazu führt, dass solche Versuche gleichzusetzen waren mit dem Versuch, HTML als Format an sich zu reißen, um diesen Schlüsselstandard künftig im Alleingang weiterentwickeln zu können. Diese Gefahr halte ich mittlerweile jedoch für geringer, eben weil das Bewusstsein für die Bedeutung unabhängiger Standards so gewachsen ist.
Mir ist es jedenfalls lieber, ein Browser implementiert mal was, das man konkret ausprobieren kann, als wenn immer erst mal ein akademischer Kreis darüber diskutieren muss, ob eine neue Idee in den Standard passt oder nicht, und Browserbauer erst dann implementieren dürfen, wenn es zumindest mal gnädigst in einen Editor's Draft aufgenommen wurde. Das empfinde ich als unnatürliche und letztlich kreativitätsfeindliche "Hörigkeit".
Ich habe es zwar auch schon als nervig empfunden, diese ganzen Präfix-Notierungen zu verwenden. Aber andererseits ermöglichen sie, Möglichkeiten schon jetzt zu nutzen, und nicht erst, wenn sie im offiziellen Standard stehen. Außerdem hat man ein Erkennungsmerkmal, damit man Sprachelemente des Standards und experimentelle Eigenentwicklungen gut auseinanderhalten kann. Insofern kann ich mich mit dieser Variante eigentlich ganz gut anfreunden. Angefangen hat damit glaube ich sogar Microsoft, und zwar mit MS Office 2000, das ja nativ alles "verlustfrei" in HTML abspeichern sollte. Und dazu benötigte man ungefähr ein paar Hundert nicht im CSS-Standard vorkommende Eigenschaften. Um die zu kennzeichnen, verwendete man das mso-Präfix.
Das ist bedauerlich. So viel habe ich davon nicht mitbekommen. Aber von der Kritik am Führungsstil der WHATWG habe ich zumindest gehört. So wie du es schilderst, scheint die WHATWG eher auf schnelle Fakten zu drängen, aus der begründeten Angst, sich so zu verzetteln wie das W3C seinerzeit mit seinen XHTML-Konzepten, und dabei aber mit straffen, wenig demokratischen Methoden vorgeht. Der Führungsstil mag kritisierbar sein, aber zumindest haben sie kapiert, dass die "Industrie" auf den neuen HTML-Standard wartet und HTML4.01 so allmählich die gleiche Patina ansetzt wie der IE6. Wenn da jetzt nicht bald was kommt, wird es überhaupt keinen Standard mehr geben.
Und wenn dann tatsächlich festgestellt werden sollte, dass es aus Sicht der Barrierefreiheit ein description-Attribut hier und da geben sollte oder dergleichen, dann kann so etwas in einem Standard, der sich nicht mehr über Jahre auf eine in Stahl gegossene Version verpflichtet, durchaus zeitnah nachgebessert werden. Das ist ja die Idee hinter dem Verzicht auf das Versionentheater. Es geht nicht darum, dass Specs keine identifizierbaren Stände mehr haben sollen. Es geht so wie ich es verstehe nur darum, davon wegzukommen, bestimmte Stände über Jahre einzufrieren, aus Angst, der Standard könne aufweichen, wenn man das nicht tut.
viele Grüße
Stefan Münz
Posting-Vorschau:
Vorschau schließen