Das kann HTML5 nicht wollen. Ansonsten wäre es den XML-Weg gegangen: Keine Angabe zur Zeichencodierung heißt UTF-8 oder UTF-16 (je nach BOM). Dann wäre für über 70% aller Webseiten gar keine Codierungsangabe erforderlich.
Du meinst, HTML5 könnte mal eben für sämtliche existierenden Dokumente eine Standardkodierung festsetzen, die von der abweicht, welche von Browser-Heuristik bestimmt wird? Woraufhin die Browser ihre Algorithmen ändern und plötzlich Millionen Seiten falsch angezeigt werden, weil ihre Kodierung eben nicht UTF-8 ist? Das hältst du für einen gangbaren Weg?
Das halte ich für ein Grundübel von HTML5: dass die Sprache nicht über eine Grammatik definiert wird, die die Sprache generiert, sondern über eine Maschine, die die Sprache verarbeitet. Das mag für einige wenige Browserentwickler der Himmel auf Erden sein, für Millionen von Webseitenentwicklern ist es die Hölle.
Ich weiß nicht, was an diesen simplen Regeln für Webseitenentwickler »die Hölle« sein soll. Hast du dafür Belege? Das Gegenteil ist doch der Fall. Der Entwickler muss sich lediglich <meta charset> merken.
Es gibt einerseits eine definierte, empfohlene Technik für Kodierungsangaben in HTML5. Diese lautet <meta charset>.
Es gibt andererseits eine definierte Technik zum Lesen von Kodierungsangaben für UAs. Die unterstützt verschiedene, auch abweichende Kodierungsangaben. »Existing content« ist hier das Stichwort.
Ich sehe nicht, wo Kodierungsangaben angeblich »über die Maschine, die sie verarbeitet« definiert werden. Es ist in HTML relativ normal, dass verschiedene Syntaxen dieselbe Semantik haben und daher gleich geparst werden.
Warum sollte ein UA solchen Schrott verarbeiten können?
Genau, warum sollten Websurfer fehlerhafte Websites überhaupt ansehen können?
Warum ist es wohl im Interesse der Browserhersteller, dass ihre Nutzer Websites ansehen können, auch wenn sie fehlerhaft sind?
Warum wollen sie nicht, dass die Nutzer zum fehlertoleranteren Browser abwandern?
»Alternativbrowser« wie Firefox einst und Opera immer noch haben schon immer mit diesem Kompatibilitätsproblem zu kämpfen. Sie konnten Fehlertoleranz nur sehr langfristig wieder ausbauen.
Diejenigen, die sich darauf einlassen, HTML zu schreiben, sollen dies richtig tun
Das Mantra ist über 10 alt und es gibt trotzdem fehlerhafte Sites und es wird auch in Zukunft fehlerhafte Sites geben, obwohl die Browser im standardkonformen Modus immer strenger werden. Jeder Browserhersteller unterhält ein Developer-Relations-Team, das den ganzen Tag nichts anderes macht, als ausgewählte Site-Betreiber zu kontaktieren und sie auf Fehler hinzuweisen, damit die Seiten im jeweiligen Browser funktionieren. Wenn ein Fehler allerdings auf einer Millionen Websites vorkommt, kann man nicht eine Millionen Betreiber kontaktieren. Der erste Stein der Fehlertoleranz wurde vermutlich von Tim Berners-Lee höchstpersönlich geworfen, als er den ersten (Tag-Soup-)HTML-Parser implementierte. Sämtliche anderen Parser mussten dazu kompatibel sein, und so kam die heutige Situation.
Und CMS, Blogsoftware etc. müssen verarbeitbares HTML (wenn schon nicht valides) generieren. Fehlerhafte Software generiert eben unbrauchbare Webseiten, wird also gar nicht verwendet und verschwindet vom Markt.
Nun, was heißt verarbeitbar? Welche Fehler sind erlaubt und welche nicht? Darüber kann man unterschiedlicher Ansicht sein. Browserhersteller beantworten sich diese Frage rein statistisch. Häufige schwerwiegende Fehler müssen berücksichtigt werden.
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. Die Zahl der Systeme, die etwa mit XML/DOM arbeiten und zuverlässig syntaktisch korrekten Code produzieren können, ist absolut gesehen vernachlässigbar. Insofern hätte XHTML 2, welches verarbeitbares Markup erfordert, einfach bedeutet, dass 95% der Websoftware Makulatur gewesen wären.
Mathias
nicht angemeldet
Gunnar Bittersmann
Der Martin
suit
