4 Kommentare

Weiterentwicklung von HTML kommt voran

Kleine News zu den aktuellen Geschehnissen rund um die neue HTML-5-Arbeitsgruppe

Im April hat sich viel getan rund um die neue neue Arbeitsgruppe des W3Cs, die HTML 4 »evolutionär« weiterentwickeln soll (wir berichteten).

Die Arbeitsgruppe ist quasi-öffentlich dadurch, dass jeder Webentwickler nach kurzer Anmeldung als »Invited Expert« beitreten kann. So beteiligten sich unzählige der üblichen Verdächtigen an den Diskussionen auf der für die Öffentlichkeit einsehbaren Mailingliste.

Es war fast zu erwarten: Vertreter verschiedener Browserhersteller schlugen vor, die Spezifikationsentwürfe der Basisorganisation WHATWG – Web Application 1.0 bzw. Web Forms 2.0, wir berichteten – als Arbeitsgrundlage für das neue W3C-HTML zu übernehmen.

Daraufhin ergab eine Abstimmung, dass die meisten Mitglieder dies befürworteten und darüber hinaus für den Namen »HTML 5« votierten. Nachdem einige formelle Einwände geäußert wurden, wird nun darüber verhandelt, unter welchen Umständen (welche Teile usw.) die WHATWG-Spezifikationen übernommen werden, um daran weiterzuarbeiten – denn Entscheidungen müssen im Konsens, das heißt ohne Einsprüche fallen.

Heiß diskutiert wurde die Frage, wie zukünftige Browser HTML 5 umsetzen würden. Chris Wilson, einer der Vorsitzenden der Arbeitsgruppe und Entwickler des Internet Explorers, erläuterte ausführlich die Position von Microsoft: »Don't Break The Web«! Damit ist gemeint, dass zukünftige Internet-Explorer-Versionen existierende HTML-Dokumente im Web nicht plötzlich standardkonform und damit komplett anders als bisher verarbeiten werden. Damit soll gesichert werden, dass bestehende Webanwendungen auch künftig mit dem IE funktionieren und Webentwicklern sowie Webnutzern nicht vor den Kopf gestoßen wird.

Microsoft favorisiert daher ein »Opt-In-Modell«, wie es schon mit dem Doctype-Switch praktiziert wird. Der Webautor muss irgendwie im Dokument angeben, dass er ausdrücklich eine Verarbeitung gemäß den Webstandards wünscht, z.B. in der Art <!-- Lieber Browser, bitte rendere meine Seite nach dem neuesten HTML-Standard! -->. Diese Position zu Abwärtskompatibilität und Versionierung von HTML fand einige Unterstützer, erntete aber auch scharfe Kritik von denjenigen, die den Teufelskreis der endlosen Abwärtskompatibilität durchbrechen möchten.

Einen Überblicksartikel zum Thema Zukunft von HTML liefert das Digital Web Magazine: HTML5, XHTML2, and the Future of the Web.

Nachtrag: Zur Diskussion um die Versionierung siehe HTML and version mechanisms im W3C Q&A Weblog.

eingeordnet unter:

veröffentlicht von molily

Kommentieren ist für diesen Artikel deaktiviert.

  1. Hallo Mathias und alle geneigten Leser!

    Erstmal vielen Dank für die Infos. Ich muss sagen, ich kann jetzt auf Anhieb nicht unbedingt ein Problem darin sehen, auch zukünftig einem Dokument eine Doctype Angabe voranzustellen.

    Es mutet allerdings schon etwas paradox an, wenn ausgerechnet Microsoft von »Don't Break The Web« spricht, wo sie doch gerade einen Großteil des heutigen Dilemmas mit zu verantworten haben.

    Aber viel interessanter als die Frage ob nun eine DTD-Angabe ja oder nein, scheint mir doch die Frage zu sein, inwieweit denn ein nicht HTML 5 fähiger Browser in der Lage sein wird, eine HTML 5 Datei noch brauchbar darzustellen?

    Einem der wesentlichsten Grundzüge folgend, nämlich Anweisungen, die er nicht versteht, schlichtweg einfach zu ignorieren, stellt sich dann für mich eben die Frage, ob eine HTML 5 Datei dann überhaupt noch "brauchbar" in einem älteren Browser dargestellt und benutzt werden kann? Wenn ich nun HTML 5 Features in meiner Seite verwende, scheint es mir von daher eher nicht angebracht, dass ein nicht HTML 5 fähiger Browser diese einfach als "normales" HTML anzeigt (und dabei die vermutlich wesentlichen Features der Webseite weglässt/ ignoriert). Alleine unter diesem Gesichtspunkt scheint mir die Beibehaltung/ Weiterführung des Systems der DTD mehr als angebracht.

    Ich glaube aber, dass dies bei weitem nicht der wesentlichste Punkt ist. Viel wesentlicher erscheint mir der Punkt, dass es bisher nicht zwingend notwendig ist, dass eine HTML Datei auch wirklich standardkonform (gemäß ihrer DTD) sein muss, damit sie von einem Browser angezeigt wird. Vielmehr versucht jeder Browser auf seine eigene Art & Weise die "Tag Soup" noch irgendwie anzuzeigen. Und wenn sich sog. "Webseitenersteller" auch noch an einem Browser orientieren, der es eh nicht so mit den Standards hat, dann ist das Problem im Bezug auf ein standardkonformes Web (und seine Abwärtskompatibilität) ja schon da.

    Hierin liegt in meinen Augen die Krux von HTML, und nicht in der Frage, ob nun eine DTD oder nicht! Also hat Microsoft so gesehen mit seiner Forderung schon Recht - auch wenn ihre Motivation/ Gründe dafür sicher ganz woanders liegen (nämlich in der Sorge, noch weitere Anteile am Browsermarkt zu verlieren und mit der aktuellen Browserentwicklung nicht Schritt halten zu können).

    Ich bin mal gespannt, was da am Ende herauskommt ...!

    Gruß Gunther

  2. Damit erhält auch der IE einen dritten Modus, welcher dem bereits verbreiten Full standard compilant Mode ähneln wird. Allerdings wird es dabei nicht bleiben. Laut Wilson soll der jeweils aktuelle Modus von einem neuen abgelöst werden, wenn der aktuelle von einer kritischen Masse verwendet wird.

    In zehn Jahren könnten wir also 5-6 verschiedene Modi im Internet Explorer haben.

    Laut Wilson ist es für Microsoft unproblematisch, mit jedem neuen Internet Explorer einen weiteren Modus einzuführen, der alle Fehlerbehebungen seit dem letzten Release enthält. Ich stelle mir aber vor, dass das aus programmiertechnischer Sicht nicht so einfach ist. Dazu kommt, dass Wilson momentan von einer neuen IE Version nur alle zwei Jahre ausgeht, woraus ich folgere, dass die kritische Masse, die den neuen Modus verwendet immer überschritten wird.

    Das Argument der Rückwärtskompatibilität wird meiner Meinung nach von Microsoft überbewertet. Ja, es gibt einige Firmeninterne Anwendungen, die auf dem IE aufbauen, aber was spricht z.B. dagegen, alte APIs für ein Release noch zu unterstützen, das ebenfalls neue und bessere APIs enthält, deren Verwendung empfohlen wird, da die alten im nächsten Release entfallen werden? Bei Wilsons' Ankündigung, der IE wird alle zwei Jahre in einer neuen Version erscheinen sollte da doch genug Zeit sein, Firmeninterne Software umzustellen.

    Was allgemein Webseiten im WWW betrifft, so ist Rückwärtskompatibilität nahezu sinnlos. Was bringt es, wenn wir ewig Fehler wie getElementByID(), welches auf das name-Attribut achtet, beachten müssen. Ich stelle mir auch vor, dass das schreiben von Webseiten schwiriger wird, weil man nun immer darauf achten muss, welchen Modus man verwendet. Hier stelle ich mir außerdem vor, dass mehrere Versionen einer Seite für 3-4 Internet Explorer Versionen geschrieben werden. Das kann nicht gut sein.

    Andererseits verliert der IE immernoch an Marktanteilen. Wenn er also ein Nachzügler bleibt (alternative Browser erscheinen etwa jedes Jahr in einer neues Version) löst sich das Problem eventuell irgendwann von selbst.

    Es tut mir leid, dass ich jetzt eigentlich nur über IE geschrieben habe, allerdings habe ich bereits fest gestellt, dass ich einerseits nicht die nötige Kompetenz habe, mich bei der Weiterentwicklung von HTML konstruktiv zu beteiligen, und andererseits ich nicht wirklich zur HTML5-Zielgruppe der RIA-Entwickler gehöre.

  3. Das Problem ist wirklich die Tag-Soup. Wenn wir mal schauen das schwierige ist ja wirklich (X)-HTML gerecht zu schreiben. Ich denke es wäre besser wenn jeder Browser nur das umsetzen würde was auch wirklich zum Standard gehört. Dabei wäres es dann wieder wichtig das alle Elemente die von allen modernen Browsern umgesetzt werden auch zum Standard gehören, gegebenenfalls zum Standard hinzufügen. Denn oft werden Tags wie <marquee> benutzt obwohl sie nicht zum Standard gehören. Darin sehe ich das Problem. Die unzähligen Tags die nicht zum Standard gehören aber trotzdem umgesetzt werden. Wenn man nun diese Tags hinzufügen würde, könnte man zur Pflicht machen, das jeder Browser eine Fehlermeldung anzeigt wenn etwas nicht kompatible ist bzw. an den Server eine Fehlermeldung schickt. Jeder der seine Kunden nicht verärgern will wird dann xhtml schreiben. Die meisten Autoren sagen sich selbst, es ist egal wie schlecht der Quelltext ist Hauptsache es merkt niemand und es funktioniert. Aber ich schätze sowas würde sehr harte Kritik bekommen. Aufjedenfall müssen aber die Programmierer solcher Browser endlich mal aufwachen. Gruß Tino </marquee>

  4. "... das schwierige ist ja wirklich (X)-HTML gerecht zu schreiben..."

    Hmm: <tag attribut="wert"></tag> bzw. <tag attribut="wert" /> ist schwierig...?

    LG Dominik