nicht angemeldet
Ah, wie konnte ich nur dem Irrglauben verfallen, HTML5 könnte eine sinnvolle durchdachte Lösung standardisieren, die dann in Browsern implementiert wird.
Lass die Polemik mal beiseite. Natürlich tut HTML5 das AUCH: Für gänzlich NEUE Features, wo noch keine bestehende Lösung existiert. Da kann man natürlich weitgehend ins Blaue hinein spezifizieren.
Die Angabe der Kodierung hingegen ist kein Tabula Rasa, wo man mal eben etwas neues erfinden kann. Man muss, zumindest wenn man HTML evolutionär weiterentwickeln will, kompatibel zu gegenwärtigen Techniken und den existierenden UAs sein. Zumindest wenn man funktionierende Websites mit effektiven Kodierungsangaben bauen will.
Diese Anforderungen werden vom in HTML5 spezifizierten Algorithmus zum Einlesen der Kodierungsangabe erfüllt. Dieser geht wie gesagt auf Browserimplementationen zurück; Grund für diese Fehlertoleranz sind Websites mit fehlerhaftem Code wie <meta content=text/html; charset=utf-8 http-equiv=Content-Tpye>. Das heißt, mit diesem Algorithmus wird das Verarbeiten von HTML-Dokumenten weitaus fehlertoleranter.
HTML5 erhebt das zum Standard, was irgendeiner der Beteiligten schon so implementiert hat, egal wie sinnlos das sein mag.
Es wird das bereits Existierende standardisiert, was Nutzwert hat.
So etwa der kurze <!DOCTYPE html>, der browserübergreifend zum Standard-Modus führt.
@charset ist genauso wenig abwärtskompatibel wie es @encoding wäre.
Nein. Warum nicht, habe ich doch detailliert in meinem Posting beschrieben. Aber ich wiederhole mich gerne:
<meta charset> unterstützen alle großen UAs bereits jetzt und taten es auch schon, bevor das Attribut in HTML5 spezifiziert wurde. Besagter Parsing-Algorithmus wurde der Browserwirklichkeit entnommen. Paving the Cowpaths: Standardisieren, was bereits De-facto-Standard ist, weil die Kurzschreibweise nützlich ist.
Insofern ist das charset-Attribut abwärtskompatibel: Kompatibel mit der Browserrealität. Nicht abwärtskompatibel mit dem vorherigen HTML-Standard. Ein UA, der streng nach HTML 4 arbeitet, kann mit <meta charset> natürlich nichts anfangen. Wer hier Abwärtskompatibilität in der Theorie gewährleistet sehen will, kann weiterhin <meta http-equiv> schreiben. Die Kurzschreibweise ist lediglich eine - schon heute weitesgehend praxistaugliche - Alternative.
<meta encoding> unterstützt hingegen noch kein Browser. Jeder müsste es erst als Neuerung implementieren, bis man diese Alternative in der Praxis ohne zusätzliches, abwärtskompatibles <meta http-equiv> verwenden könnte. In welchem Zeitraum tauschen sich sämtliche UAs aus, sodass man eine solch grundlegende Technik wechseln kann? Sicher nicht im Laufe von 10 Jahren. Wir haben immer noch mit IE 6 und 7 zu tun.
Mathias
Gunnar Bittersmann
Der Martin