Bewegung im W3C

The plan is to charter a completely new HTML group.

(Mit „group“ ist eine Working Group des W3C gemeint, die Arbeitsgruppen, die sich um die Entwicklung konkreter Standards kümmern)

Warum ist das nun interessant? Eine HTML Working Group gibt es doch schon und sie ist durchaus beschäftigt, auch wenn man sich um das Ziel der Beschäftigung durchaus streiten kann. Dazu muss man etwas in der Geschichte der Spezifikationsentwicklung des W3C’ herumwühlen, insbesondere in der letzten Zeit.

Vorsichtig, es ist lang.

(X)HTML

Die bisherige Meinung beim W3C zur Entwicklungsgeschichte von HTML sieht so aus:

  1. HTML 2.0, HTML 3.2 und HTML 4.01 werden in relativ rascher Folge nacheinander entwickelt. HTML 4.01 war die letzte größere Veränderung und Weiterentwicklung von HTML und es erschien 1999.
  2. XML tauchte am Horizont auf, eine vereinfachte Variante des Dokumentenauszeichnungsstandard SGML. XML sollte die Zukunft des Webs sein.
  3. Konsequenterweise wird HTML 4.01 in XML reformuliert, es entsteht XHTML 1.0. Dabei wurde nichts hinzugefügt, aber auch nichts wirklich wichtiges weggelassen. XHTML 1.0 ist also nur HTML 4 im XML-Gewand, dadurch wird es im wesentlichen etwas strikter und weniger fehleranfällig geschrieben und man könnte es mit jedem XML-Tool verarbeiten. Um abwärtskompatibel zu HTML zu bleiben wird ein Modus eingeführt, XHTML 1.0 so zu schreiben, dass ein HTML 4 verstehender Browser es als HTML versteht und nicht über das XML stolpert.
  4. Es wird weiter an den HTML-in-XML-Spezifikationen gebastelt, XHTML wird modularisiert, d.h. in Einzelteile aufgesplittet. Die Idee dahinter ist es, das man neue XHTML-Teilmengen aus den unterschiedlichen Modulen zusammenbasteln kann, konsequenterweise wird das auch gemacht, XHTML Print ist ein XHTML für Gedrucktes, XHTML Basic ist eine XHTML für Browser auf kleinen Geräten, Mobilfunkgeräte und PDAs, insofern ist es der Nachfolger von WML.
  5. XHTML 1.1 ist die Zusammenfassung aller Module aus der Modularisierung von XHTML – inklusive des Moduls Ruby. Letzteres ist für eine spezielle Schreibweise bei asiatischen Sprachen zuständig, die einzige wirklich substanzielle Neuerung seit HTML xml-isiert wurde. Der abwärtskompatible Modus ist hier nicht mehr vorhanden, XHTML 1.1 soll nur noch als XML verarbeitet werden.
  6. XHTML sollte die Zukunft sein.

Zwei Dinge sind bei dieser Vision des W3C bemerkenswert, die Revolution durch XML fand nicht statt und es bleibt die Frage nach der Weiterentwicklung des (X)HTML-Sprachstandards.

XML? Wo?

Tatsächlich findet in unseren Browserfenstern so gut wie kein XML statt. Der offensichtlichste Grund ist natürlich, dass haufenweise Webseiten im Internet sich so gut wie nicht um korrektes Markup kümmern, es werden einfach Tags an Tags gehäuft und gehofft, dass der Browser das schon richtig macht. Dann gibt es haufenweise HTML-Seiten, die naturgemäß nicht XML sind.

Aber selbst wenn man seine Dokument gemäß den Regeln von XHTML, genauer den Regeln des abwärtskompatiblen Modus von XHTML 1.0 bastelt, klappt es nicht. Denn die Browser verarbeiten das abwärtskompatible XML als HTML. Im Browser hat man also kein XML, sondern HTML. Würde man das XHTML als richtiges XML schicken, macht natürlich ein Browser nicht mit, der liebe Internet Explorer. Dummerweise ist es noch der wichtigste Browser im derzeitigen Web.

Die Revolution durch XML fand nicht statt. Tim Berners-Lee:

Some things are clearer with hindsight of several years. It is necessary to evolve HTML
incrementally. The attempt to get the world to switch to XML, including quotes around
attribute values and slashes in empty tags and namespaces all at once didn’t work. The large
HTML-generating public did not move, largely because the browsers didn’t complain.

HTML ist da, es wird bei uns bleiben und nicht weggehen, so sehr man sich das auch wünschen mag.

XHTML 2

Seit 1999, seit HTML 4.01 gab es keine größere substanzielle Weiterentwicklung von HTML 4 bzw. XHTML 1 mehr. Am Sprachbestand hat sich nichts verändert, außer XHTML Ruby wurden keine neuen Elemente eingeführt, bestehende Elemente wurden nicht erweitert. Dabei hätte man vieles durchaus brauchen können, stattdessen wird viel mit JavaScript gemacht. Und es werden haufenweise eigene Elemente erfunden: <div id="header">, <div id="sidebar">, etc. Wo fand die Innovation bei HTML statt?

Tatsächlich gibt es eine Weiterentwicklung von (X)HTML, XHTML 2.0, seit mindestens 2002 in der Mache und kein Ende in Sicht. Abgesehen von der langen Wartezeit – Standards brauchen durchaus Zeit – gibt es aber Probleme mit XHTML 2. Zum einen ist es wie XHTML 1.1 reines XML, d.h. man kann es nicht wirklich in derzeitigen Browsern zum Laufen kriegen, siehe IE.

Zum anderen ist es keine Weiterentwicklung im Sinne von weiter sondern eine Neuentwicklung. Diesmal wollte man es richtig machen, komisches Zeug aus HTML-Zeiten loswerden, neuen Krempel möglichst intelligent entwerfen und Spezialfälle möglichst verallgemeinern. Da gibt es durchaus nette Dinge, jedes Element kann nun ein Hyperlink sein, jedes Element kann nun ein Bild sein (und trotzdem strukturierten alternativen Inhalt enthalten), es gibt neue Elemente wie eine allgemeine Überschrift <h> …. Das ist alles nicht das Problem mit XHTML 2. Der Punkt ist, dass in XHTML 2 Dinge aus den Zeiten von XHTML 1 durch anderes ersetzt werden. Konsequenterweise ist ein in XHTML 1 geschriebenes Dokument kein richtiges (valides) XHTML-2-Dokument mehr. Und es geht nicht um eine leichte Veränderung wie Syntax wie beim Sprung von HTML 4 auf XHTML 1, sondern um richtige Elemente.

Zum Beispiel Formulare. In XHTML 2 werden nicht mehr die Formulare wie in HTML-Zeiten verwendet wie reine input-Elemente, sondern es wird eine neue Formularbeschreibungssprache genutzt, XForms. Und XForms definiert nicht einfach neue Kontrollelemente für Formulare, es ist komplexer. Man definiert (in XML) ein Modell für seine gewünschten zu sammelnden Daten, verknüpft dieses Modell mit XML Schema, um diese Daten zu validieren und bindet dieses Modell mittels XPath an XForms-Formularkontrollelemente um daraus eine XML Repräsentation des Modells mit den tatsächlichen Daten, um diese übers Kabel zu schicken. Wer den Satz bis zum Ende verstanden hat, dürfte jetzt auch an MVC denken und liegt richtig damit. Und ja, im Prinzip hat man durch XForms viele Vorteile, automatische Validierung von Formularen, mehr Kontrolle über das, was über die Leitung geht, Berechnungen von Formularinhalten und eine bessere Integration mit DOM Events bzw. XML Events.

Das Problem dabei ist, dass XForms einen ganzen Rattenschwanz von Techniken nach sich zieht, XPath, XML Schema, XML Events und natürlich leben alle XForms-Elemente in einem eigenen XML-Namensraum. Für XML-Erfahrene und Programmierer ist dies weniger ein Problem; Otto Normal-Pixelschubser wird allerdings vor einigen Hürden und einer großen Lernkurve stehen. Das einfache (X)HTML-Formular, das er eben noch geschrieben hat, kann er beim hypothetischen Umstieg auf XHTML 2 nicht einfach so lassen oder gar erweitern, nein, er muss es neu schreiben und dies ganz anders als gewohnt, und um XForms effizient nutzen zu können, braucht er sehr viel mehr Wissen.

Diese Nicht-Abwärtskompabilität und Ersetzung von gewohnten Konzepten ist in XHTML 2 gewünscht. Frames? Ersetzt durch XFrames. Access-Keys? Ersetzt durch ein ganz neues Element, dass seine Ziele mit XPath oder mit WAI-Rollen adressiert. Die einfachen on-*-Attribute? Ersetzt durch eine neue XML-Sprache, XML Events, die besser mit dem DOM Event Konzept harmonieren. Es ist eben eine Neuentwicklung.

XHTML 2 ist ein großes, komplexes Biest, auf das man nicht man eben so mit seinen (X)HTML-Dokumenten umsteigen kann, man müsste ziemlich viel dazulernen, was man bisher ignorieren konnte. Konsequenterweise ist auch so gut wie kaum was davon, nur Einzelteile, in den Browsern implementiert, bzw. es wird versucht, Dinge zu implementieren. Das sieht nicht gerade toll auf Seiten des W3C aus.

WHAT?

Tatsächlich hat das W3C in den letzten Jahren sehr viel Kritik einstecken müssen; Stagnation, Wolkenkuckuckskonsortium und Ignoranz der tatsächlichen Realitäten gehörten dazu. Mathias Schäfer beschreibt diese ausführlicher im Artikel Mikrofortschritte und stellt unter anderem auch vermeintliche Konkurrenzgruppen vor. Die hervorstechendste dürfte die Web Hypertext Application Technology Working Group sein, kurz WHAT WG. Diese ist ein Zusammenschluss von Herstellern moderner Browser, genauer Mozilla, Opera und Apple und derzeit zahlt Google dem Editor der WHAT WG sein Gehalt. Durchaus beachtliche Mitspieler im Web. Und man sieht die Entwickler der diversen Browser durchaus auf der Mailingliste. Die Gruppe gründete sich im Juni 2004 als Reaktion auf einen Workshop des W3Cs zum Thema Web Applications, der entgegen der Ansichten von Mozilla und Opera sich auf ein Modell von Web Applications versteifte, das nicht auf dem bekannten HTML/CSS und JS aufbaute, sondern wieder neuere Techniken und vor allem XML-Techniken nutzte. Revolution im Sinne von XHTML 2 statt Evolution bestehender Standards.

Die WHAT WG begann damit, eine Alternative zu den bereits bemängelten XForms zu entwickeln, WebForms 2.0. WebForms ist eine Erweiterung der bereits existierenden Formulare von HTML um neue Möglichkeiten der Eingabe wie kalendarische Daten (<input type="date">), spezielle Strings (<input type="email">), um Minima und Maxima (<input type="number" min="3" max="10">), Reguläre Ausdrücke für Texteingabefelder und mehr. Im Wesentlichen all die Werte, die man heutzutage noch mit JavaScript überprüft. Weitere Datentypen in HTML zu spezifizieren hat aber den Vorteil, dass der Browser zusätzlich spezielle Varianten der Eingabe dieser Daten anbieten kann, für kalendarische Daten einen Kalender oder für Nummern in einem definierten Abschnitt einen Slider.

Noch schöner ist es, dass WebForms 2.0 abwärtskompatibel ist, soll heißen, ein bestehendes (X)HTML-Formular ist auch immer ein richtiges WebForms-2.0-Formular. Man könnte also Schritt für Schritt seine bestehenden HTML-Dokumente erweitern. Abwärtskompatibilität und Kompatibilität zu bestehenden Standards ist für die WHAT WG wichtig. Das merkt man auch in dem Entwurf für HTML 5.

HTML 5

Auch aus dem Hause WHAT WG ist der Entwurf Web Applications 1.0, auch als (X)HTML 5 bekannt. HTML 5 ist eine Spezifikation, die versucht das bisherige Gemisch von HTML 4/XHTML 1 und den für HTML verantwortlichen DOM-Spezifikationen zu nehmen, zu integrieren, bestehende Quasi-Standards (XMLHttpRequest) mit zu integrieren und dieses abwärtskompatibel zu erweitern. Das klingt nach viel, es ist auch viel. HTML 5 definiert …

  • DOM-Interfaces für alle Elemente
  • DOM-Interfaces für bestehende Konventionen wie innerHTML
  • neue DOM-Interfaces für nützliche Dinge, wie die Abspeicherung von Daten im Browser für Sessions oder für Domains
  • HTML-Attribute und DOM-Interfaces, die man nutzen kann, um Elemente editierbar (contenteditable) oder mittels Drag-and-Drop verschiebbar zu machen
  • Einen simpleren Modus des Parsens von HTML – eine Reaktion auf die Tatsache, dass kein Browser HTML wirklich streng nach den Regeln von SGML parst.
  • und natürlich neue Elemente wie <nav>, <header>, <m> für markierten Text, <progress> für Fortschrittsbalken …

HTML 5 ist eine chaotische Spezifikation, ständig im Umfluss, ständig in der Veränderung, kein Wunder, ist es doch erstmal nur ein Working Draft. Und es zieht auch wegen vermeintlicher Kurzsicht der Autoren Kritik auf sich. Joe Clark kritisiert in der für ihn typischen Polemik How not to fix HTML teilweise zu Recht den Technozentrismus der Autoren, er wünscht sich mehr aus dem Leben gegriffenen Neuerungen, Elemente wie Annotationen und Fußnoten – all die Möglichkeiten des Ausdrucks, die man auch im Print hat. Allerdings: Es ist ein Working Draft, alles ist noch möglich.

HTML 5 und die WHAT WG hat den Vorteil, dass die Browser-Hersteller dahinter stehen und mitwirken. Teilweise werden Dinge der WHAT WG schon implementiert. Opera 9 hat eine rudimentäre Implementierung von WebForms, Firefox 2 hat das DOM Storage Interface aus HTML 5 implementiert.

Und das W3C?

Das W3C hat im November 2005 drei neue Working Groups gegründet, darunter besonders interessant die Web API WG mit ihrem schönen Beta Logo. Diese WGs haben zur Aufgabe, Techniken rund um Rich Web Clients zu spezifizieren, also das, was mit Web Anwendungen im Browser zu hat und dort nützlich sein kann. Spezifikationen, die dort unterwegs sind:

  • XMLHttpRequest, die Spezifikation des beliebten Ajax-Objektes und dessen Verhaltens.
  • Die Spezifikation des window-Objektes, das jeder nutzt, für das es aber bislang noch keine authorative Quelle gab.
  • Die Spezifikation einer Selectors API – die in etwa dasselbe macht wie die beliebte Javascript-Bibliothek jQuery, nämlich HTML-Elemente mittels CSS-Selektoren zu identifizieren.
  • Die Spezifikation des Dateiübertragungsmechanismus inklusive Manipulationsmöglichkeiten durch JavaScript.
  • und mehr ist in Planung.

Einige dieser Spezifikationen haben ihren Ursprung in HTML 5, tatsächlich sind die Spezifikationen und ihre Autoren im Wesentlichen von der WHAT WG zum W3C gewandert. Man kann die WHAT WG insofern nicht als Konkurrenz zum W3C betrachten, sondern als Vorarbeiter. Als ein Platz, wo von den Browserherstellern (und Nutzern) angedacht wird, was nützlich wäre und in Gedankenspielen experimentiert wird. Reift etwas oder liegt es auf der Hand, dass etwas sinnvoll ist, wird damit dann zum W3C gegangen. Tatsächlich ist das auch die Intention der WHAT WG:

Many of the members of this working group are active supporters and members of the W3C
and other standardization bodies. Parts of the work have already been submitted to the W3C,
and we intend to work more closely with the W3C in future. The technical work is currently
focused on developing the specifications to levels appropriate for the W3C Last Call stage.

WebForms 2.0 wurde bereits als Submission beim W3C eingereicht, auch wenn der Kommentar des W3C angesichts der Existenz von XForms eher lau war. Aber das W3C erkennt langsam durchaus an, dass es einen Bedarf an Weiterentwicklung anhand des realen Webs und anhand der realen Bedürfnisse von Webentwicklern gibt. Dies mit einer besonderen Betonung auf Weiterentwicklung im Gegensatz zu ständigen das Rad neu erfindenden Neuentwicklungen.

Zurück zu Sir Tim

Mit der Ankündigung von Tim Berners-Lee wird diese Anerkennung auch auf HTML ausgeweitet, ging es vorher immer nur um kleinere Legosteine, ist hier ein großer Block zur Weiterentwicklung zur Verfügung gestellt, HTML. Er sagt da einige interessante Dinge:

The plan is to charter a completely new HTML group. Unlike the previous one, this one will be
chartered to do incremental improvements to HTML, as also in parallel xHTML.

HTML wird weiterentwickelt und zwar inkrementell, hier bedeutet das soviel wie abwärtskompatibel, in kleinen, verdaubaren Schritten. Gleichzeitig auch XHTML, aber vermutlich nur die Variante XHTML 1, denn:

There is also a plan for a separate group to work on the XHTML2 work which the old “HTML
working group” was working on. There will be no dependency of HTML work on the XHTML2
work.

XHTML 2 bleibt weiterhin eine komplett neue, für sich stehende Entwicklung ohne großen Bezug zu HTML 4+ und XHTML 1+. Aber immerhin, das bestehende HTML soll weiterentwickelt werden. Auch die Formulare:

There will also be work on forms. This is a complex area, as existing HTML forms and XForms
are both form languages. HTML forms are ubiquitously deployed, and there are many i
implementations and users of XForms. Meanwhile, the Webforms submission has suggested
sensible extensions to HTML forms. The plan is, informed by Webforms, to extend HTML
forms. At the same time, there is a work item to look at how HTML forms (existing and
extended) can be thought of as XForm equivalents, to allow an easy escalation path. A goal
would be to have an HTML forms language which is a superset of the existing HTML language,
and a subset of a XForms language with added HTML compatibility.

Soll heißen: HTML-Formulare werden inspiriert durch WebForms weiterentwickelt. Etwas problematischer ist der zweite Aspekt, zu gucken, ob man WebForms mit XForms vereinheitlichen kann. Dies dürfte tatsächlich auf einen Vorschlag von IBM zurück gehen. Im Prinzip klingt das paradiesisch, die einfache Nutzung von WebForms mit der Mächtigkeit von XForms vereint. Dennoch dürfte dabei wahrscheinlich eine komplexere Variante von XForms herauskommen, wie Henri Sivonen anmerkt. Dennoch denke ich, dass das W3C diesen Pfad weiter verfolgt, schließlich ist es ein Industriekonsortium und IBM ist durchaus an XForms interessiert, soweit ich das mitbekommen haben.

Aufbruch

Es wäre auch illusorisch zu glauben, das W3C würde nun einfach die Vorschläge der WHAT WG übernehmen, schon allein weil HTML 5 kein durchgereifter, konzeptionell in sich abgeschlossener Vorschlag ist, sondern vielmehr eine Ideensammlung, die durchaus Kritik verträgt. Ich denke nicht, dass das W3C HTML 5 als Vorlage, denn mehr als Inspiration nehmen wird. Wichtiger ist, dass das W3C die konzeptionellen Gedanken hinter der Arbeit der WHAT WG übernimmt, Abwärtskompatibilität, die Realisation des real existierenden Webs und vor allem die Zusammenarbeit mit Browserherstellern:

We have strong Support for this group, from many pople we have talked to, including browser makers.

Ich denke, den Internet Explorer kann man wie gewohnt hier ausklammern. Dennoch ist es ein Zeichen der Bewegung im W3C, dass sich zu lange auf große monolithische Neuerfindungen des Rades konzentriert hat. Man kann nur hoffen, dass daraus auch etwas wird.

10 Kommentare » Schreibe einen Kommentar

  1. Noch einen kleinen Zusatz:

    vielleicht wäre es sinnvoll bevor eine dieser großen Neuerungen 4.2 herauszubringen und darin alle Elemente die umgesetzt worden sind (bei allen modernen Browsern) zu implementieren.

  2. Hi,

    Gunther hat einen sehr schönen Text geschrieben auf den ich jetzt zurückkommen will. Meiner Ansicht nach müssten sich alle am Riemen reisen wenn das noch was werden will.

    Wenn die Autoren invalides HTML zustandebringen sind sie zum Teil Schuld, da aber Browser damit werben die besten Seiten "herzustellen" müssen sie es umsetzen. Da die Browser es umsetzen können die Autoren es dann wieder schreiben.

    Nun will ich auf eine ganz andere Sache kommen: Elemente die nicht Standard sind, aber gebraucht werden. Das bekannteste Beispiel ist wahrscheinlich das "marquee" Element. Durch die Erfindung von Mircosoft konnten sehr viele WYSIWYG-Editoren Lauftexte anzeigen. Andere Möglichkeiten sind:

    -Grafik

    Natürlich nicht ideal weil man Grafik anzeigen deaktivieren bzw. bei
    Textbrowsern sie überhaupt nicht sieht

    -Script

    Eigentlich genau das gleiche wie bei Grafik. Es ist nicht umbedingt Javascript eingestellt.

    Wenn man nun weiterdenkt: Jeder Browser unterstützt mittlerweile dieses Format. Bei einer Seite, die mit einem WYSIWYG-Editor erstellt wurde kamen 25% Fehler alleine durch dieses Element. Lösung: Ins Standard aufnehmen und gut ist. Natürlich gibt es jetzt noch viel mehr Beispiele die ich jetzt aber aufgrund der Länge nicht sagen will. Das W3C sollte wirklich schauen was gebraucht wird, nicht was sie wollen was umgesetzt wird.

    Ich habe es sehr schön gefunden als Browser die die Standards unterstützen groß geworden sind. Vielleicht sollten einfach alle Browser bei einem Fehler kommen und ausgeben: "Dieses Dokument ist nicht valid." Dann würden sich ein paar Leute an die Standards halten.

    Bis zum nächsten Kommentar
    Tino

  3. Hallo zusammen!
    Ich sehe die Dinge etwas pragmatischer. Das W3C kann ja Standards entwickeln, weiterentwickeln und festlegen wie es lustig ist. Aber das wird auf nicht absehbare Zeit nichts daran ändern, dass Standard allenfalls die Schnittmenge der Fähigkeiten ist, die alle verwendeten Browser unterstützen. Denn solange der Browser am Ende der Kette steht, ist und bleibt er der ausschlaggebende Faktor. Andere Ausgabemedien als Screens seien jetzt mal außen vor gelassen.

    Und solange wie User verschiedenste Browser verwenden, die ganz unterschiedliche Fähigkeiten besitzen, kann man imho in der Praxis wenig mit den vom W3C festgelegten Standards anfangen. Darin liegt m.E. eines der Hauptprobleme der Weiterentwicklung im Web. Das W3C setzt sich (überwiegend) aus Leuten zusammen, die ihre Brötchen bei anderen Vereinen verdienen, und somit natürlich auch die Wahrung deren Interessen im Hinterkopf haben (müssen). D.h. das W3C hat quasi keinerlei Einfluss und Macht, die Umsetzung ihrer Standards in der Praxis auch durchzusetzen, sondern ist sozusagen auf das Goodwill der jeweiligen Firmen und Organisationen angewiesen, seinen Standards und Empfehlungen auch zu folgen.

    Wie gut so etwas in der Praxis tatsächlich funktioniert, sieht man sehr deutlich am Beispiel von Microsoft.

    Erschwerend hinzukommt, dass sich das W3C durch seine Vorgehens- und Arbeitsweise in der Vergangenheit, selbst nicht immer mit Ruhm bekleckert hat, und somit seinem Ruf eher geschadet als genützt hat.

    Wenn Dinge aus Anforderungen der Praxis heraus erwachsen sollen, dann muss eine deutlich schnellere Umsetzung als bisher erfolgen. Bestes Beispiel ist doch CSS. Wie alt ist die CSS 2.0 Spezifikation? Und wie sieht es mit ihrer Implementierung in den heute am häufigsten verwendeten Browsern aus? Und wie lange wird es wohl noch dauern, bis wir die meisten Module der CSS 3 Spezifikation als Standard ansehen dürfen?

    Meiner Ansicht nach, sollte man primär erstmal das Bewusstsein der Anwender, im Bezug auf die von ihnen verwendeten Browser und die damit verbundenen Folgen für die Weiterentwicklung des Webs, schärfen.

    Für mich sitzen ganz klar die Browserhersteller am längsten Hebel. Theoretisch könnte man das W3C auch ganz abschaffen, wenn sich die Browserleute einig wären, und sich gänzlich zu ihrem eigenen Kaffeeklatsch treffen würden.

    Und das neuerliche Herausbringen eines weiteren Browsers von MS, wird den "Durchbruch" von XML/ XHTML wieder um Jahre verzögern. Wenn es dann überhaupt noch einen interessiert, denn wir sprechen hier immer von Zeiträumen, die in diesem Bereich eher einem Jahrhundert gleichen. Früher glaubten die Leute auch mal, irgendwann im Pferdemist zu ersticken, falls die Zahl der Fuhrwerke weiter so ansteigen sollte!

    "Gewaltenteilung" ist halt nicht immer das Beste. Andererseits hat es das W3C aber auch bis heute nicht geschafft, einen Browser rauszubringen, der ihre eigenen Spezifikationen richtig und vollständig umsetzt. Amaya ist diesbezüglich wohl auch eher in die Kategorie "Blamage" einzuordnen.

    Also können die sich beim W3C von mir aus ruhig weiter "ausmalen" wie schön das Web sein könnte – spätestens beim Blick auf mein Browserfenster lande ich wieder auf dem Boden der harten Realität.

    Einen anderen Aspekt sollte man bei diesen ganzen Überlegungen seitens des W3Cs auch nicht außer Acht lassen: Einer der Gründe, warum das Web so erfolgreich geworden ist, ist sicherlich auch der Umstand, dass HTML relativ einfach (zu erlernen) ist. Durch diesen Umstand war das Web zu Beginn ein Medium, wo sich jeder relativ schnell mit seinen Inhalten einbringen konnte. Ich sehe die Gefahr, dass zukünftige Entwicklungen zu "kompliziert" werden – der produktive Zugang also erheblich erschwert wird – "Keep it simple!".

    Ich frage mich auch, warum Dinge bspw. in (X)HTML integriert werden müssen, die man schon heute mit Hilfe weit verbreiteter Scriptsprachen lösen kann?

    Die "Ideallösung" wird es ohnehin nie geben. Stellt sich die Frage, ob man sich bei der Weiterentwicklung mehr an dem Ideal orientieren sollte, oder vielmehr unter Berücksichtigung der tatsächlichen Ist-Zustände und aktuellen Gegebenheiten versuchen sollte, die Anforderungen und Erfordernisse möglichst schnell und einfach umzusetzen? Ich tendiere da eher zu Letzterem.

  4. Ja, also klasse wäre das schon. Dann würde auch was passieren — mit der Kundensicht.
    Gezwungermaßen so zu sagen! Mit der Einstellung "wie es unter der Weboberfläche aussieht geht mich nix an und is mir völlig wurscht" wäre es dann Essig. Nachhaltige und zukunftssichere Designqualität wär dann question of matter.

  5. Bogus spricht da einen wichtigen Punkt an! Es ist immer die Rede von den "Browser-Herstellern", die ja jetzt immer mit am Tisch sitzen, wenn neue Standards geformt werden. Genauso wichtig wie die Browser-Hersteller sind jedoch die Hersteller von WYSIWYG-Editoren, denn hier schlummert die wahre Bremse für die Standards.

    Wir werden niemals flächendeckend hochsemantische Websites erreichen, denn dafür ist WYSIWYG schlicht ungeeignet. Aber zumindest könnte man die Tools dazu bringen, validen und well-formed Quelltext auszuspucken. Der ist dann zwar sematintisch verarmt, aber vielleicht wenigstens standardkonform.

    Und ich persönlich halte viel von XHTML als Idee. Und noch mehr von einer Anreicherung durch weitere, sinnvolle Tags. Ob man dazu eine dritte Arbeitsgruppe benötigt, wage ich jedoch zu bezweifeln. Sollen sich doch die XHTML2-Leute und WHATWG zusammenraufen und fusionieren. Kann doch so schwer nicht sein, die verfolgen doch letztlich das gleiche Ziel!

  6. Sehr intressant zu lesen, das Hauptprolem ist aber doch das solche Programme wie Frontpage die User dazu aninmieren, einfach nur so hingeklaschte Webseites zu erstellen. Die meisten wissen nicht mal wie sie im Code eine Bild ändern.
    Die Herstellern von solchen Programmen sollte man mehr mehr dazu "verpflichten" auf die Standards zu achten

  7. Danke für diese Zusammenfassung, Tim. Hat diese Entwicklung Auswirkungen auf SELFHTML 9? Wird es sich weiter auf das ältere HTML 4 konzentrieren oder auf XHTML setzen? Mit der Meldung von Tim Berners-Lee scheint sich der Weg zu XHTML wohl erstmal zu verlangsamen …

    Ich stimme Thomas Meinike zu, dass es besser wäre _eine_ Schiene zu fahren anstatt an HTML und XHTML gleichzeitig weiterzuschrauben. Ist doch prinzipiell erstmal egal, ob XHTML in Browsern als text/html verarbeitet wird.

  8. Wenn es ein HTML 5 sein muss, dann bitte im Sinne eines XHTML 1.5 als Vorstufe zu XHTML 2.0. Das W3C sollte die (zu) vielen existierenden Baustellen aufräumen und die besten Ideen zusammenführen.

  9. Hallo Tim, exzellente und sehr bemerkenswerte Übersicht über den aktuellen Status Quo. Und eigentlich ist die ganze verfahrene Situation einfach nur traurig, wobei es genügend Anzeichen in der Vergangenheit gab, dass das mal so endet.

  10. Im nachhinein ist es enfach zu sagen was man hätte machen sollen, z.B. die Leute erst einmal auf valides HTML 4.1 strict umsteigen lernen lassen. Wie sieht es denn da mit HTML 5 aus, wird es da wieder zwei Varianten geben? Nett wäre es wenn man da weitermachen würde wo man mit 4.1 strict aufgehört hat, also trennung von Inhalt und Layout.