Kommentare zu dieser Meldung: 18

Michael Jendryschik meinte am 22.11.2005:

Sie stellen in Ihrem Artikel fünf Punkte heraus, die gegen XHTML sprechen sollen, dies meines Erachtens aber nicht annähernd tun.

1. Die Entscheidung, nicht alle Möglichkeiten einer Technik nutzen zu können oder wollen, ist weder ein Argument für, noch ein Argument gegen diese Technik.

2. Dass XHTML 1.1 derzeit aus den von Ihnen aufgeführten Gründen nicht eingesetzt werden kann, ist richtig, aber auch daraus lässt sich kein Argument gegen XHTML 1.0 ableiten. Nur weil der neue Golf 5 Ihnen nicht gefällt, werden Sie Ihren alten Golf 4 nicht gegen einen noch viel älteren Golf 3 eintauschen. ;-)

3. Aus der Tatsache, dass Webautoren XHTML als text/html ausliefern können, wenn sie sich an die HTML-Kompatilitätsrichtlinien halten, kann ich ebenfalls kein Argument gegen XHTML ableiten, eher im Gegenteil.

4. Auch die aktuelle Entwicklung von XHTML 2 spricht nicht gegen XHTML 1.0. Nur weil die aktuellen Studien des zukünftigen Golf 6 Ihnen nicht zusagen, werden Sie Ihren alten Golf 4 nicht usw.

Ich gebe Ihnen Recht, wenn Sie schreiben, dass XHTMLs »Coolness-Faktor« sich abgenutzt habe, aber seien wir ehrlich: Na und? Ich müsste regelmäßig große Teile meiner CD-Sammlung entsorgen, machte ich mich davon abhängig, welche Interpreten und Musikrichtungen gerade cool sind.

Falls Sie in diesem Kommentar Argumente für XHTML vermissen, so seien Sie gewiss, ebenso vermisse ich in Ihrem Artikel echte Argumente gegen XHTML und wirklich schlüssige Gründe für Ihren Umstieg.

Viele Grüße,
Michael Jendryschik

ML meinte am 22.11.2005:

Ich begrüße die Entscheidung von EfA für HTML. Das ist der richtige Weg.

@jendryschik:

Es gibt mindestens ein schlüssiges Argument gegen XHTML. Punkt 3! Lesen Sie einfach mal hier dazu:

http://annevankesteren.nl/2005/11/xhtml-advocates
und
http://annevankesteren.nl/2004/08/xhtml-media-types

Ebenso ist natürlich auch Punkt 4 ein wichtiges Argument. Denn besonders beim Thema Barrierefreiheit spielt Abwärtskompatibilität eine wichtige Rolle.

Rainer Schlegel meinte am 22.11.2005:

Wieso spricht Punkt 1 gegen XHTML? Um bei Michael Jendryschik zu bleiben: Der Coolnes-Faktor der heutigen Schulmedizin hat sich schon lange abgenutzt und im täglichen Krankenalltag brauchen wir sie nicht immer. Also behandelt Ihr in Zukunft Eure grippalen Infekte wieder mit Zwiebelsaft und Halswickel und macht einen großen Bogen um die Apotheke? Und ob man wirklich auf transitional angewiesen ist oder im Zeitalter leistungsfähiger CMS nicht auch andere Lösungen findet, sei mal dahingestellt.

Und wenn man jetzt XHTML 1.0 einsetzt heißt das ja nicht, dass man demnächst sofort bei Erscheinen auf Version 2 umschwenken muss. Soviel zur beschworenen Abwärtskompatibilität.

Martin meinte am 22.11.2005:

Dem IE kann man laut W3C XHTML als application/xml ausliefern. http://www.w3.org/MarkUp/2004/xhtml-faq#ie

icwiener meinte am 23.11.2005:

Ich bin irgendwie nciht überzeugt von den angegebenen Gründen.

1. Eine der Eigenschaften einer Kerze ist, dass sie Wärme abgibt. Diese Eigenschaften brauche ich nicht, also zünde ich keine Kerzen an.

2. Der nächste logische Schritt beim Autokauf ist, sich nach 2 Jahren das Nachfolgemodell zu kaufen.

3. Entfällt. Mit MIME-Types im IE kenne ich mich nicht aus. ;)

4. Ein Duden kann auch als Briefbeschwerer verwendet werden. Er hat dann jedoch keine Vorteile gegenüber einem gewöhnlichen Briefbeschwerer. Also kaufe ich keinen Duden.

5. Morgen wird es regnen, deshalb gehe ich heute nicht aus dem Haus.

Es werden sich auf der Sitzung hoffentlich mehr als nur diese Gründe herauskristallisiert haben.
Und ich hoffe, dass die Punktabzüge für HTML4.01 hier absichtlich weggelassen wurden, da der Artikel ja davon Handelt, warum es nicht für XHTML gereicht hat.

Aber als Webmaster mehrere Seiten, worunter einige ähnlichen Umfangs wie diese hier sind, kann ich behaupten, dass XHTML1.1 nicht die schlechteste Wahl war. Ich musste ein paar Dinge anders lösen, als ich es gewohnt war, aber auf den Mehraufwand bin ich stolz. Und das hat mit Coolness nichts zu tun. Es ist ein Fortschritt, mit dem ich schrittzuhalten versuche.
Es war auch für die Primaten nicht notwendig, sich auf 2 Beinen in die Steppe zu begeben. Aber ... hmm, naja... über das Ergebnis lässt sich streiten. ;)

Fazit: Ich bin etwas enttäuscht über diesen Schritt. Es hinterlässt irgendwie einen Eindruck von "es ist einfacher so" oder auch "der IE kann es nicht, also tun wir's nicht". Und so verständlich/notwendig diese Denkweise doch ist, sie stößt mir doch bitter auf.

MfG

ND meinte am 23.11.2005:

Ein sehr schwacher Artikel, den ich hier so nicht erwartet hätte. Die eigentliche Entscheidung EfA zukünftig in HTML 4.01 zu gestalten, scheint irgendwo versteckt zu sein, im Artikel selbst steckt er jedenfalls nicht. In den (bereits trefflich kommentierten) Punkten finden sich die Argumente schlussendlich nicht.
Wenn dieser Artikel anderen Webdesignern/-entwicklern etwas hilfreiches mit an die Hand geben möchte, so lassen sich die Aussagen auf folgende Punkte reduzieren:

- XHTML 1.1 kommt für EfA nicht in Frage, weil eine 'transitional' Variante benötigt wird.
- XHTML 1.1 kommt nicht in Frage, weil der notwendige Mime-Type vom Marktführer nicht unterstützt wird
- Die Wahl der Variante 'strict' ist allemal entscheidender als die Entscheidung zwischen X und Nicht-X HTML

Um XHTML insgesamt gleich ins Abseits zu stellen, finde ich keine Anhaltspunkte. Und Aussagen im Stile von "es war mal cool in XHTML zu machen, aber jetzt bin ich erwachsen" fallen wohl auch nicht in den Bereich der Sachlichkeit.

Warum also HTML 4.01 strict einem XHTML 1.0 strict (als text/html) vorziehen?

Da hier, scheinbar schon für die Zukunft, eine Erweiterung des Sprachraums ausgeschlossen werden kann scheint es wirklich auf einerlei herauszulaufen. Aber das gilt halt nicht unbedingt als Vorbild für andere Projekte und sicher auch nicht für jene die nicht so gut in die Zukunft blicken können.
Meine Entscheidung würde an dieser Stelle immer andersherum ausfallen. Aber ich bin mir auch sicher nahezu immer von der Sprachraumerweiterung zu profitieren (Stichwort: TALES).Wenn Herr Caspers die Entscheidung anders treffen kann, dann ist es für diesen Fall auch gut. Wenn dies ein Zeichen werden soll oder eine Enttäuschung über XHTML ausdrücken soll, welches in einer realen Welt hinter den Erwartungen zurück bleibt, dann kann ich das auch akzeptieren. Aber dann hätte dies auch bitte so im Artikel stehen sollen und nicht so ein hinkender Vergleich im Wettkampfstil mit "Coolness-Faktor".

Herr Caspers, da sind wir ansonsten aber besseres gewohnt.

Jens Meiert meinte am 23.11.2005:

Die hier aufgefuehrten Anmerkungen sind sicherlich an einigen im Artikel verwendeten Formulierungen festzumachen. Insgesamt moechte ich deshalb auf jeden Fall zwei Aspekte im Bezug auf HTML nochmal betonen:

* Es ist absolut legitim, HTML zu verwenden (mit Augenmerk auf Validitaet und Semantik, natuerlich - und wie immer).

* XHTML muss eigentlich mit dem richtigen MIME-Typ ("application/xhtml+xml") ausgeliefert werden (bis auf "XHTML 1.0 Transitional", das auch als "text/html" angeboten werden /darf/), und nur so kommt man auch in den Genuss der eigentlichen Vorteile von XHTML [...]. Wenn man nicht konform vorgehen kann (IE), sollte man den Einsatz von XHTML auch ruhig, na, vertagen duerfen.

Martin Kliehm meinte am 24.11.2005:

Ich muß Ihnen leider in allen Punkten widersprechen:

1. Eine Erweiterbarkeit ist kein Nachteil gegenüber HTML, somit auch Grund für einen Punktabzug. Es geht nicht darum, ob Sie mathematische Formeln einbinden wollen, sondern darum, nur die Module zu verwenden, die Sie benötigen. Zum Beispiel, um das Target-Modul einzubinden, das im XHTML-Basis-Set nicht enthalten ist. Oder um XHTML um ein start-Attribut für OL-Elemente zu erweitern. Haben Sie darüber einmal nachgedacht?

2. Entfällt. Da XHTML erweiterbar ist (das X in XHTML), besteht keine Notwendigkeit für Transitional, somit kann auch XHTML 1.1 Strict mit einer erweiterten DTD gewählt werden.

3. Wir verwenden XHTML 1.1 Strict in Kundenprojekten und liefern es mit dem korrekten MIME-Type "application/xhtml+xml" nur für Browser (und den W3C Validator) aus, die im HTTP-ACCEPT-Header explizit XHTML vermerkt haben. Der Internet Explorer 6 hat das nicht, also bekommt er den MIME-Type "text/html". Das stellt überhaupt kein Problem dar. Im Gegenteil, die Qualität unseres Codes ist gestiegen, da uns Fehler in Firefox sofort angezeigt und somit vermieden werden können. Übrigens gehe ich davon aus, daß IE7 XHTML nativ versteht. Was machen Sie in einem halben Jahr? Wieder einen Relaunch?

4. Die Seiten verhalten sich, wenn sie mit dem MIME-Type "text/html" ausgeliefert werden nicht automatisch so, als wären sie HTML 4.0. Sie meinen bestimmt, daß dann vom standard-kompatiblen Modus in den Quirks-Modus umgeschaltet wird, dem ist aber nicht so. Mit einer eigenen, erweiterten DTD landen Sie (in Mozilla) immer im standard-kompatiblen Modus: http://www.mozilla.org/docs/web-developer/quirks/doctypes.html

5. XHTML 2.0 wird zwar nicht mehr abwärtskompatibel sein. Aber bis es zu einer breiten Anwendung kommt, werden noch etwa fünf Jahre vergehen. Und XHTML ist valides XML: XML verstehen Browser schon jetzt. Man kann also schon heute Seiten in XHTML 2.0 entwickeln, die validieren und von Browsern angezeigt werden können. Steven Pemberton, der Chairman der XHTML Working Group, gibt dafür Beispiele in seinem Tutorial: http://www.w3.org/2005/Talks/04-19-steven-XHTML2-XForms/

Ich halte es für ignorant, sich aus diesen fadenscheinigen Gründen und mangelhafter Information gegen eine etablierte Technologie zu entscheiden.

Und heißt es nicht in der BITV-Anlage §11.1 "Es sind öffentlich zugängliche und vollständig dokumentierte Technologien in ihrer jeweils aktuellen Version zu verwenden". Die aktuellste Version von HTML ist XHTML 1.1.

Im übrigen fände ich es angemessener, sich mit der Zugänglichkeit der eigenen Seite auseinanderzusetzen. Zum Beispiel kommt die Fehlermeldung zur Anmeldung, um hier einen Kommentar zu schreiben, nicht zu Beginn der Seite, sondern erst am Ende. Abgesehen von der unsäglichen Formulierung "Klicken Sie hier" bei der Registrierung.

ML meinte am 24.11.2005:

@Martin Kliehm:

»Übrigens gehe ich davon aus, daß IE7 XHTML nativ versteht.«

wird er nicht. Das ist schon seit geraumer Zeit klar.

»4. Die Seiten verhalten sich, …«

doch tun sie. Denn MIME-Typen etnscheiden, wie der Browser das Dokument parst. DOCTYPEs entscheiden über Standard-, Almost-Standard- oder Quirks-Modus.

»Die aktuellste Version von HTML ist XHTML 1.1.«

Falsch. Die aktuellste Version von HTML ist HTML 4.01 bzw. HTML 5 (ist nur noch nicht fertig). XHTML ist eine Neuformulierung von HTML in XML. HTML basiert aber auf SGML.

XHTML 2 wird in den nächsten 10 Jahren sicherlich nie zu einer breiten Anwendung kommen. Zumindest nicht bei Browsern etc. Denn Browser müssen abwärtskompatibel sein.

Noch ein (echtes) Argument gegen (echtes) XHTML:
Wird XHTML mit dem richtigen MIME-Typ ausgeliefert, muß der Browser zuerst die kompletten daten erhalten und parsen, bevor er etwas darstellen kann. HTML wird Stück für Stück geladen und dargestellt.

Martin Kliehm meinte am 24.11.2005:

@ML:

MK: »Übrigens gehe ich davon aus, daß IE7 XHTML nativ versteht.«
ML: »wird er nicht.«

Wird er doch. Nur den MIME-Type nicht: http://blogs.msdn.com/ie/archive/2005/09/15/467901.aspx

MK: »4. Die Seiten verhalten sich, …«
ML: »doch tun sie. Denn MIME-Typen entscheiden...«

Der angegebene Link sagt, daß eigene DTDs in Mozilla als Strict geparst werden.

ML: »Wird XHTML mit dem richtigen MIME-Typ ausgeliefert, muß der Browser zuerst die kompletten daten erhalten und parsen, bevor er etwas darstellen kann.«

Bei Dateigrößen von 10-20 Kilobyte fällt die Ladezeit wohl kaum ins Gewicht. Ich habe extrem selten Seiten mit mehr (X)HTML-Code.

Martin meinte am 24.11.2005:

"»Die aktuellste Version von HTML ist XHTML 1.1.«

Falsch. Die aktuellste Version von HTML ist HTML 4.01 bzw. HTML 5 (ist nur noch nicht fertig). XHTML ist eine Neuformulierung von HTML in XML. HTML basiert aber auf SGML."

Und was ist XML? Eine Teilmenge von SGML.

"Noch ein (echtes) Argument gegen (echtes) XHTML:
Wird XHTML mit dem richtigen MIME-Typ ausgeliefert, muß der Browser zuerst die kompletten daten erhalten und parsen, bevor er etwas darstellen kann. HTML wird Stück für Stück geladen und dargestellt."

Das ist definitiv falsch. Opera stellt auch XHTML 1.1 mit dem richtigen Mime-Type schon beim Laden dar und Geckos könnten es auch: https://bugzilla.mozilla.org/show_bug.cgi?id=18333

ML meinte am 24.11.2005:

@Martin Kliehm

»Wird er doch. Nur den MIME-Type nicht«

ohne richtigen MIME-Type ist es kein XHTML.

»Der angegebene Link sagt, daß eigene DTDs in Mozilla als Strict geparst werden.«

Richtig. Wird das Dokument als »text/html« gesendet, wird es mit dem »tagsoup«-Parser im Strict-Modus geparst. Ein XML-Parser hat nur einen Modus. Nochmal: Der MIME-Type entscheidet welcher Parser genommen wird, entweder ein XML-Parser oder der »tagsoup«-Parser. Ein Invalides XHTML-Dokument wird, wenn als »text/html« ausgeliefert, wie ein invalides HTML-Dokument dargestellt. Ein »Error« wird nur angezeigt, wenn es als XML geparst wird.

Solange der IE XHTML nicht »versteht«, gibt es keinen Grund es einzusetzen, da er es weiterhin wie HTML behandelt. Wielange hat es gedauert bis Microsoft den IE von V6 zu V7 weiter entwickelt hat? Und wie hoch ist der Marktanteil des IE? Warum XHTML, wenn man mit HTML dasselbe erreicht?

Martin Kliehm meinte am 25.11.2005:

@ML:

»Warum XHTML, wenn man mit HTML dasselbe erreicht?­«

Qualitätssicherung: Firefox zeigt Fehler im XML sofort an, da wir ihm wie beschrieben den XHTML-MIME-Type liefern.

Forcierung der Trennung von Layout und Semantik durch den Wegfall der Layout-Attribute.

Zukunftskompatibilität. Mir graut immer wenn ich Seiten sehe, bei denen das Frontend-Wissen der Entwickler offenbar 1998 stehengeblieben ist.

Importierfähigkeit als XML-Includes (von serverseitigen XForms will ich gar nicht erst anfangen).

Die Frage ist also eher: Warum also HTML, wenn ich mit XHTML dasselbe und noch mehr erreiche?

Tomas Caspers meinte am 25.11.2005:

> Qualitätssicherung: Firefox zeigt Fehler
> im XML sofort an

Das macht bei uns bereits der Editor unserer Wahl, sodaß solche Fehler erst gar nicht auf den Server gelangen.

> Forcierung der Trennung von Layout
> und Semantik durch den Wegfall
> der Layout-Attribute.

Grober Unfug. Die Grenze verläuft bei diesen Dingen zwischen strict und transitional, nicht zwischen XHTML und HTML.

> Zukunftskompatibilität

Was bitte genau ist an validem, semantischem HTML (ohne X) nicht zukunftskompatibel?

> Importierfähigkeit als XML-Includes (von
> serverseitigen XForms will ich gar nicht
> erst anfangen).

Danke, aber wir haben für unsere Zwecke hier keinerlei Bedarf an dem einen oder an dem anderen. Wo liegen dann also die Vorteile von XHTML?

Harald Kampen meinte am 13.12.2005:

Die ganze Argumentation zur Rückkehr nach HTML überzeugt mich nicht. Vieles wurde hier schon geschrieben, ich muss das nicht wiederholen.

Ich sehe das als eine gelungene Provokation an. Mit der Entwicklung in Richtung XHTML 2 bin ich auch nicht glücklich. Und HTML, ob mit X oder ohne, das nicht fehlertolerant ist, wird auf Dauer nicht funktionieren.

Ansonsten hoffe ich, irgendwann mal SVG in meine PHP-XHTML-Seiten einbetten zu können - und das geht nun mal nicht mit HTML.

Tomas Caspers meinte am 13.12.2005:

> Die ganze Argumentation zur Rückkehr
> nach HTML überzeugt mich nicht.

Die Argumentation zum Verbleib bei XHTML war auch nicht gerade überzeugend. Einwände wie "XHTML kann man erweitern, wenn einem die Elemente nicht ausreichen" sind im Tagesgeschäft nicht wirklich zu gebrauchen - wir schreiben hier lieber für Menschen, nicht für Maschinen.

> Ansonsten hoffe ich, irgendwann mal
> SVG in meine PHP-XHTML-Seiten einbetten
> zu können - und das geht nun mal nicht
> mit HTML.

Nö, aber mit HTML 5 gibt's <canvas>, das jetzt schon eine bessere Unterstützung hat als SVG nach all den Jahren. Ob das wohl daran liegt, dass die W3C-Spezifikationen mittlerweile nicht mehr les- und verstehbar sind?

Hans Krentel meinte am 23.11.2006:

Der Artikel mag zwar die interne Entscheidung der EfA wiedergeben, aber warum wir er veröffentlicht? Gehört das nicht in euer Intranet?

Den gerade durch die Veröffentlichung erweckt der Artikel den Eindruck, das generell HTML barrierefreier als XHTML sei. Dies ist ein falsches Signal. XHTML ist zu HTML abwärtskomtabel und bietet somit nicht nur allen alten Browsern sondern auch noch vielen neuen Browsern und Tools eine standarisierte und vorallem einfach umsetzbare Schnittstelle. Hier werden keine Barrieren aufgebaut, sondern abgebaut.

Eine Seite wie EfA, die damals nicht schnell genug die Tabellen aus dem Webdesign verbannen konnte und durch den daraus resultierenden CSS overkill die Browser bei menschen mit und ohne behinderung somit zum Stillstand brachte (!) sollte sich mal praxisorienter zeigen und dran denken: Bei den alten Browsern immer noch ein parr CPU-Zyklen für den Screenreader übrig lassen. Die konnten das CSS nämlich noch nicht einfach wegschalten.

soophie meinte am 22.06.2007:

Ich kann Herrn Michael Jendryschik nur zustimmen. Ich brauche da nichts mehr zu zu sagen. Ich verwende XHTML, da ich das teilweise Wischwasch von HTML 4 nicht mag. Einige Elemente müssen geschlossen werden, andere dürfen. Nö, dann lieber strikt XHTML und einfach alles schließen.

Kommentar abgeben?

 

Ihr Kommentar:

Tipp: HTML ist nicht zulässig; Webadressen können Sie so: [url=domain.de]Text[/url] eingeben.

Ihr Name:

Ihre E-Mail-Adresse: (wird nicht veröffentlicht)

URL: (wird bei Spamverdacht gelöscht)

Kommentar senden