Bekomme Quirks-Mode nicht weg

[Gunnar Bittersmann]

@@molily:

nuqneH

Du meinst, HTML5 könnte mal eben für sämtliche existierenden Dokumente eine Standardkodierung festsetzen

Nein, natürlich nicht für „sämtliche existierenden Dokumente“. HTML5 hätte aber UTF-8/16 für neue als HTML5 gekennzeichnete Dokumente festlegen können.

Ich weiß nicht, was an diesen simplen Regeln für Webseitenentwickler »die Hölle« sein soll.

Zum einen ist der von HTML5 genannte Algorithmus kaum das, was ich mir unter „simplen Regeln“ vorstelle.

In HTML 4.01 hingegen „können HTML-Dokumente explizite Angaben über die Zeichenkodierung des Dokuments enthalten; das META-Element kann benutzt werden, Benutzerprogrammen diese Information zur Verfügung zu stellen.
Zum Beispiel sollte ein Dokument die folgende META-Deklaration enthalten, um zu spezifizieren, dass die Zeichenkodierung des aktuellen Dokuments »EUC-JP« ist: <META http-equiv="Content-Type" content="text/html; charset=EUC-JP">“ [§5.2.2]
Und [§3.2.2] sagt, dass in diesem Fall Anführungszeichen um den Attributwert stehen müssen.

Zum anderen war das nicht auf diesen Fall bezogen., sondern allgemein. HTML5 beschreibt, wie sich ein Parser bei bestimmtem Code zu verhalten hat. Als Webautor möchte ich aber wissen, wie mein Code überhaupt auszusehen hat. Völlig andere Herangehensweise. Als Webautor ist man mit simplen Grammatikregeln weitaus besser dran als mit ellenlagen kaum verständlichen Parsingregeln. Solche bei HTML5 durchlesen zu müssen, ist eine Zumutung.

Warum sollte ein UA solchen Schrott verarbeiten können?
Genau, warum sollten Websurfer fehlerhafte Websites überhaupt ansehen können?

Hier generalisierst du, wo ein konkreter Fall gemeint war, nämlich <meta content=text/html; charset=utf-8 http-equiv=Content-Type>. Seit wann hat dieser fehlerhafte Code funktioniert? Wieviele Webseiten verwenden diesen fehlerhaften Code? Warum wurde an dieser Stelle eine Fehlertoleranz in Browser implementiert, die vermutlich mehr Probleme schafft als löst?

Bestehende Software ist schon konzeptionell nicht dazu in der Lage, wohlgeformtes HTML zu produzieren, da Templatesysteme auf der Verkettung von Strings basieren, nicht auf einem Objektmodell.

Da fehlte wohl ein Wort: … nicht dazu in der Lage, _ausschließlich_ wohlgeformtes HTML zu produzieren? Natürlich kann man mit Stringverkettung valides HTML produzieren. (BTW, gibt es sowas wie „wohlgeformtes HTML“?) Man kann allerdings auch Müll produzieren. Man hat es als Autor selbst in der Hand.

Insofern hätte XHTML 2, welches verarbeitbares Markup erfordert, einfach bedeutet, dass 95% der Websoftware Makulatur gewesen wären.

Nein, keinesfalls. Die Implementierung von XHTML 2 in Browser hätte nicht bedeutet, dass Browser bestehende und neue Dokumente nicht mehr als Tag-Soup verarbeiten könnten. Websoftware hätte weiterhin Tag-Soup generieren können.

Qapla'