XHTML 2 ist jetzt auch offiziell klinisch tot.
Tim Tepaße
XHTML 2 ist jetzt auch offiziell klinisch tot.
Tim Tepaße
Hallo,
das W3C hat angekündigt, dass die XHTML 2 Working Group nach ihrem Auslaufen am Ende dieses Jahres nicht erneuert wird und bietet eine kleine FAQ dazu an. Die XHTML 2 WG ist die frühere HTML WG, die damals beibehalten wurde, als eine neue HTML WG für HTML 5 gegründet wurde. Die HTML WG kümmerte sich also um HTML 5 und XHTML 5, die XHTML 2 WG führte die XHTML 1.x Anstrengungen und den Neu-Entwurf XHTML 2 weiter, allerdings natürlich nicht sehr angestrengt.
Ich bin etwas skeptisch, anstatt nun den Tod der Wicked Witch of The West zu feiern. Natürlich war XHTML 2 ein größeres Biest wie ich mal im Weblog schrieb. Natürlich krankte es ziemlich unter der nicht vorhanden Rückwärtskompabilität und dem Nutzen komplizierter externer Module. Aber als ein reines totes Elfenbeinprodukt mag ich es auch nicht betrachten. Einige der in XHTML 2 aufgezeigten möglichen Innovationen mag ich. Und guckt man sich andere an, dann sind das nicht unbedingt irgendwelche Spielereien, sondern hinter jedem Feature steht ein Problemfall, ein Bedürfnis. Das wirkliche Hauptproblem lag nicht in deren Neuerungen, sondern in dem kompletten Verzicht auf einen sanften Weg von HTML 4/XHTML 1 zu XHTML 2. Manche der in XHTML 2 angedachten Dinge wurden als Einzelmodule rausgelöst und auch in XHTML 1 nutzbar gemacht, wie das Role Attribute oder die Meta-Informations-Struktur, die sich dann zu RDFa entwickelte. Mein Hauptproblem ist, dass diese sinnvollen Dinge dann von (X)HTML 5 ignoriert werden. Ähnlich wie die XHTML 2 WG unter einem „Jetzt mal richtig“-Syndrom litt, leidet die HTML WG bzw. die einzig dort Entscheidungen treffende Person unter einem „not invented here“-Syndrom, das besonders gegen XHTML 2 gerichtet ist. Die Einführung von Microdata vor ein paar Wochen, obwohl RDFa existiert, auf einem kleinen Massstab verbreitet ist und von zwei großen Suchmaschinenherstellern unterstützt wird, ist da nur ein Beispiel für. Es ist schade, dass damals XHTML 2 und (X)HTML 5 nicht aufeinander zu gehen konnten.
Tim
-
growf!
*für morgen schwarze Klamotten rauskram*
Kommentar kommt noch.
Gruß,
Harlequin
--
<!--[if lt IE 8]>This page is best viewed with a webbrowser. Get one today!<![endif]--> -
Hallo,
ich habe ich schlimme Vermutung, dass wir das, was gegenwärtig »mit uns passiert« in puncto HTML (5), erst in einigen Jahren verstehen und Ross und Reiter erkennen werden. Dann ist es natürlich zu spät und wir werden uns zumindest teilweise über einiges schwarz ärgern. Der gegenwärtige Hype um HTML 5 scheint ähnlich beknackt abzulaufen wie einst der um XHTML. Aus Markup-Sicht ist HTML 5 derzeit Tag Soup, ein alter Hut, mit ein paar neuen Elementen, denn eine echte HTML-5-konforme Verarbeitung gibt es noch nicht.
»HTML 5« als derzeit gebrauchtes Schlagwort, vor allem wie es gegen XHTML 2 in Anschlag gebracht wird (»Hurra, XHTML 2 ist tot, es lebe HTML 5«), wird daher eher als Konglomerat aus JavaScript- und CSS-Techniken wahrgenommen. Die Hälfte der Webentwickler muss ja denken, HTML 5 sei das, was Google als HTML 5 verkauft (Google Wave und Co.), und dass runde Ecken, Box- und Textschatten, Halbtransparenz und Farbverläufe auch dazu gehören. Gut, HTML 5 besteht tatsächlich aus dutzenden Scripting-APIs. Gerade deshalb scheint mir der öffentliche Fokus gänzlich vom Markup entfernt zu haben. XHTML 2 sollte eben mehr sein als ein paar neue Elemente. Und die DOM-Arbeitsgruppe wollte etwas anderes tun als proprietäre Erfindungen spezifizieren.
Im Nachhinein halte ich viele Argumente gegen XHTML 2 für vorgeschoben - vielleicht abgesehen von der Kompatibilitätsfrage. Dass es eine unmögliche Mammutaufgabe sei, dass Browser und Authoring-Tools eine komplett neue Sprache wie XHTML 2 implementieren, wurde dadurch widerlegt, dass unzählige neue API für HTML 5 in kürzester Zeit implementiert wurden. Die Browserhersteller hatten einfach entsprechende Interessen.
Mathias
-
Hi,
Die Browserhersteller hatten einfach entsprechende Interessen.
Und das hatten sie, seit Netscapes Marc Andreessen das W3C innovationsmäßig vor sich her trieb.
Wohin das geführt hat, sehen wir ja. Wenn es ähnlich weiter geht, kann es so schlecht nicht werden ...
... zumal der Browserkrieg wohl beendet ist.
Gruß, Cybaer
--
Zweck des Disputs oder der Diskussion soll nicht der Sieg, sondern der Gewinn sein.
(Joseph Joubert, Schriftsteller)
-
Wenn es ähnlich weiter geht, kann es so schlecht nicht werden ...
Es kann nicht schlecht werden, weil bereits alles gut ist, also gut geworden ist? Seltsame Argumentation. Ich denke nicht, dass alles gut geworden ist.
Es entstehen Spezifikationen, Sprachen und APIs, auf die sich die Hersteller mehr oder weniger formell oder informell geeinigt haben. Zu 90% lief das so, dass ein Browser sie erfunden hat und die anderen gezwungen waren, sie durch Reverse-Engineering nachzubauen, wenn sie die ungefähre Stoßrichtung nützlich fanden. Jetzt werden diese standardisiert. Nicht, weil sie unbedingt toll sind, sondern weil sie sich in der Praxis durchgesetzt haben. Weil ein Browserhersteller Fakten geschaffen hat und andere nachziehen mussten.
Ist das jetzt gut? Das einzig Gute, was ich daran sehen kann, ist, dass die vorhandenen Techniken hoffentlich irgendwann recht breit unterstützt werden. Wie tauglich und verständlich diese Techniken nun sind, steht auf einem anderen Blatt.
... zumal der Browserkrieg wohl beendet ist.
Ist er das? HTML 5 ist die Fortsetzung des Browserkrieges mit anderen Mitteln.
Mathias
-
Hallo Molily,
Es entstehen Spezifikationen, Sprachen und APIs, auf die sich die Hersteller mehr oder weniger formell oder informell geeinigt haben. Zu 90% lief das so, dass ein Browser sie erfunden hat und die anderen gezwungen waren, sie durch Reverse-Engineering nachzubauen, wenn sie die ungefähre Stoßrichtung nützlich fanden. Jetzt werden diese standardisiert. Nicht, weil sie unbedingt toll sind, sondern weil sie sich in der Praxis durchgesetzt haben. Weil ein Browserhersteller Fakten geschaffen hat und andere nachziehen mussten.
Es hat sich aber gezeigt, dass es anders offenbar nicht wirklich geht. Wenn das Prozedere der Standardisierung nicht von konkreten, an Alltagsproblemen orientierten Interessen geleitet wird, sondern von einem perfektionistischen Ewigkeitsanspruch, dann wird der Standard 1. nie fertig und 2. nicht alltagstauglich.
Ich bin auch kein Freund davon, wenn Standards letztlich nur "Industriestandards" sind und keine Standards, die ohne Schielen nach links oder rechts der menschlichen Weitsicht entspringen. Aber lieber ein halbwegs vernünftiger Industriestandard, als gar keiner.
Im übrigen glaube ich auch nicht, dass HTML 5 total naiv und falsch wahrgenommen wird. Gut, das könnte sich ändern durch Marketing-Aussagen wie "Google Wave is a HTML 5 aspplication". Doch momentan sehe ich durchaus ernste Bemühungen, die Möglichkeiten von HTML 5 zu verstehen und auszuloten. Ein gutes Beispiel dafür ist der Dr.Web-Artikel JavaScript animiertes Säulendiagramm mit HTML-Canvas.
viele Grüße
Stefan Münz -
Hi,
Es kann nicht schlecht werden, weil bereits alles gut ist, also gut geworden ist?
Nein. wir haben ein hier eine Systematik (ob nun erwünscht und wirklich gut sei dahingestellt), die das Web weit vorangebracht hat. Dagegen hat uns W3Cs XHTML-Zukunft *praktisch* nirgendwohin gebracht.
Ich sehe deswegen also mit Optimismus in die Zukunft ...
Ist das jetzt gut? Das einzig Gute, was ich daran sehen kann, ist, dass die vorhandenen Techniken hoffentlich irgendwann recht breit unterstützt werden.
Das ist das Relevante. Was nützen mir beste Theorien (worüber sich zudem trefflich streiten läßt), wenn sie nie Praxis werden ...
... zumal der Browserkrieg wohl beendet ist.
Ist er das? HTML 5 ist die Fortsetzung des Browserkrieges mit anderen Mitteln.IMHO: Ja. MS hat sich zu den Standards bekannt - auch zu HTML 5.
Es gibt nach wie vor Unterschied, und wird sie auch zukünftig geben. Aber das alle Browser den identischen (CSS/JS/HTML-)Leistungsumfang bieten und sich nur durch Gescchwindigkeit, GUI und Endanwenderfeatures unterscheiden, hätte ohnehin kein W3C-Standard erreicht ...
Gruß, Cybaer
PS: Und alles wird gut! ;-)
--
Zweck des Disputs oder der Diskussion soll nicht der Sieg, sondern der Gewinn sein.
(Joseph Joubert, Schriftsteller)
-
Yerf!
Nein. wir haben ein hier eine Systematik (ob nun erwünscht und wirklich gut sei dahingestellt), die das Web weit vorangebracht hat. Dagegen hat uns W3Cs XHTML-Zukunft *praktisch* nirgendwohin gebracht.
Bei der Entwicklung von XHTML ist leider einiges schiefgelaufen. Aber HTML5 bringt uns auch nicht wirklich vorwärts...
Ich sehe deswegen also mit Optimismus in die Zukunft ...
Ich nicht... wir werden wie gehabt vorwärtsstolpern und "irgendwie" gehts auch weiter, aber einen echten Fortschritt kann man das einfach nicht nennen.
Das ist das Relevante. Was nützen mir beste Theorien (worüber sich zudem trefflich streiten läßt), wenn sie nie Praxis werden ...
Was nützt mir die Praxis, wenn sie für meine Zwecke nicht ausreicht?
PS: Und alles wird gut! ;-)
... für Liebhaber von HTML 3.2 ;-)
Gruß,
Harlequin
--
RIP --- XHTML 2
nur die Besten sterben jung -
wir haben ein hier eine Systematik (ob nun erwünscht und wirklich gut sei dahingestellt), die das Web weit vorangebracht hat. Dagegen hat uns W3Cs XHTML-Zukunft *praktisch* nirgendwohin gebracht.
Des W3Cs XHTML-Zukunft hat uns dahin gebracht, wo wir jetzt sind: zu (X)HTML 5. Das XML-Ökosystem, das für XHTML 2 geplant war, und das HTML-5-System sind nicht disparat. Web Forms war eine Antwort auf XForms und HTML 5 »The Markup Language« hat viele Einflüsse von XHTML 2 aufgenommen. Wenn man von HTML 5 die Scripting-APIs, das Tag-Soup-Parsing und die »HTML-5«-Serialisierung wegnimmt, ist es HTML 4 mit neuen Elementen und Attributen, deren Funktionalität das XML-Ökosystem im Groben ebenfalls abdecken bzw. bewusst aus Gründen auslagern wollte. HTML 5 ist da nichts komplett anderes, sondern übernimmt Ideen und Techniken auf die eine oder andere Weise. Darauf hatte Tim schon im Eingangsposting hingewiesen. Neuere Diskussionen, selbst XML-Sprachen wie SVG in das Tag-Soup-Universum zu integrieren, zeigen doch, dass man sich freudig aus dem Fundus des W3C-XML-Frameworks bedient, aber dabei Techniken umdeutet oder neu erfindet, wie es einem gerade passt. Was dann herauskommt, entspricht nicht unbedingt den Zielen, welche das W3C mit seinen Techniken verfolgt. Man denke nur an Canvas, das jetzt schon für gänzlich unzugängliche UIs verwendet wird, die selbst mit Flash oder SVG weitaus zugänglicher wären. Oder an <video> und <audio>, welche weit hinter den (auch Zugänglichkeits-)Fähigkeiten von SMIL zurückbleiben. Es hat eben alles seine zwei Seiten.
Was nützen mir beste Theorien (worüber sich zudem trefflich streiten läßt), wenn sie nie Praxis werden ...
Spezifikationen werden Praxis, wenn sie jemand implementiert. HTML-5-Unterstützung fällt auch nicht vom Himmel. Man muss nur wollen. Bei XHTML 2 wollte niemand, bei HTML 5 muss niemand mehr wollen, weil die Techniken ohnehin aus der Feder der Browser-Coder stammen und zuerst da waren.
Mathias
-
Hi,
Wenn man von HTML 5 die Scripting-APIs, das Tag-Soup-Parsing und die »HTML-5«-Serialisierung wegnimmt, ist es HTML 4 mit neuen Elementen und Attributen,
Und ebenfalls neu ist, IMHO ganz wichtig, die Definition, daß unbekannte Elementen und Attribute im DOM abzubilden sind.
Man denke nur an Canvas, das jetzt schon für gänzlich unzugängliche UIs verwendet wird,
<gebetsmuehle type="personal" mode="on">Beurteile eine Technik nie danach, wie sie mißbraucht wird.</gebetsmuehle> ;)
Spezifikationen werden Praxis, wenn sie jemand implementiert. HTML-5-Unterstützung fällt auch nicht vom Himmel. Man muss nur wollen. Bei XHTML 2 wollte niemand, bei HTML 5 muss niemand mehr wollen, weil die Techniken ohnehin aus der Feder der Browser-Coder stammen und zuerst da waren.
Na ja, bis HTML 5 umgesetzt ist, wird es schon noch ein Weilchen dauern ...
Gruß, Cybaer
--
Zweck des Disputs oder der Diskussion soll nicht der Sieg, sondern der Gewinn sein.
(Joseph Joubert, Schriftsteller)
-
-
-
-
-
-
Und tschüß!
Gruß, Cybaer
--
Zweck des Disputs oder der Diskussion soll nicht der Sieg, sondern der Gewinn sein.
(Joseph Joubert, Schriftsteller)
-
Finde ich sehr schade und ich finde es nicht gut, dass die beiden Standards oftmals gegeneinander "ausgespielt" wurden. Ich fand beide Ansätze super und ich hätte gerne beides zur Verfügung gehabt und je nach Projekt kann ich dann entscheinden "ganz dolle sauber, total semantisch und überhaupt" zu schreiben (XHTML). Oder eben "sieht gut aus, macht was es soll und NetScape4 kann es auch anzeigen" (HTML).
Jetzt "verlieren" wir ersteres und wie gesagt finde ich das sehr schade. Ich hätte es gerne gesehen dass diese beiden Sprachen sich nach dieser Trennung wieder aufeinander zu bewegen bzw. voneinander lernen.Das wirkliche Hauptproblem lag nicht in deren Neuerungen,
sondern in dem kompletten Verzicht auf einen sanften Weg
von HTML 4/XHTML 1 zu XHTML 2.Ach komm schon! Das war ein Verzicht auf den "sanften Weg"? Bitte?
Erst kam 4 dann 1.0 dann 1.1 trans dann 1.1 strict und dann wäre jetzt 2 gekommen. Wer möchte kann hier noch die "Module" sich dazwischen denken... wie wäre es denn noch sanfter? Soll der ganze alte Kram denn gültig bleiben wo die meisten entsprechenden Elemente eh schon "nicht empfohlen" waren?
XHTML2 war mir absolut sanft genug, damit sollte eigentlich niemand überfordert sein und es gab eine Evolution, also dass das jetzt der harte Schnitt gewesen wäre würde ich nicht so sehen wollen.Scoring: Der Betreff enthält nur große Buchstaben (-3.00 Punkte).
Jaja, wie immer!