nicht angemeldet
Warum maßt sich die WHAT WG an, das Web neu zu erfinden und Bestehendes abzuschaffen, nur weil die den Sinn nicht erkennen?
Man sollte nicht nur Fragen stellen, sondern ihnen auch auf den Grund gehen.
Es war nicht die WHATWG, sondern die W3C HTML WG hat hier ganz offiziell nach ihren geltenden Verfahren entschieden:
http://lists.w3.org/Archives/Public/public-html/2011Mar/0398.html
Das Grundproblem hier scheint zu sein, dass
1. viele bestehende Dokumente http-equiv="Content-Language" entgegen der in HTTP spezifizierten Bedeutung, stattdessen im Sinne von html@lang zur Angabe der Textsprache verwenden,
2. viele UAs http-equiv="Content-Language" in diesem Sinne verarbeiten, um die Textsprache zu extrahieren, wenn html@lang nicht angegeben ist.
Grundfrage ist also, wie mit dieser Situation umzugehen sei.
Es gab drei Change Proposals mit Abstimmung, wobei Ian Hickson gleich zwei entgegengesetzte vorgelegt hat. Zu allen hat sich auch die W3C I18n WG ausgelassen (bist du da nicht aktiv und sitzt näher an der Quelle?).
Übrigens kann man die Sprache(n) des Zielpublikums natürlich weiterhin im HTTP-Header angeben, lediglich die HTTP-EQUIV-Angabe im Dokument soll in HTML5 nicht mehr möglich sein. Sinnvoll?
Sie sind in der Praxis eben nicht äquivalent (s.o.). Und waren es vermutlich auch nie (http-equiv war ursprünglich als Anweisung für HTTP-Daemons gedacht, wurde aber nie so verarbeitet).
Natürlich kann man sich hier auf den Standpunkt stellen, den UAs einfach vorzuschreiben, dass sie die Spracherkennung auf Basis von http-equiv="Content-Language" ausbauen sollen, wie es die I18n WG getan hat:
»We would prefer that the CP [to let multiple language tags continue to be legal] be modified so that browsers must not guess at the default language for the page by looking at the HTTP headers and/or meta elements. This would result in a CP that does not remove or change the http-equiv information (as the "non-conforming" CP proposes) but would render it harmless.«
Aber das würde vor allem dazu führen, dass unzählige Sites plötzlich bspw. nicht mehr von Screenreadern vorgelesen werden können, weil nur http-equiv="Content-Language" angeben. Kein UA wird das, was momentan ein wichtiges Feature ist und von Webautoren tausendfach eingesetzt wurde, plötzlich ausbauen. Das nur als Vorgeschmack auf die langen und kontroversen Diskussionen in der HTML WG.
Alles in allem ist das eine sehr verfahrene Situation, in der jede Entscheidung einige Vorteile hat und gleichzeitig schwerwiegende Probleme nach sich zieht. Ehrlich gesagt finde ich die von den Chairs getroffene Entscheidung recht salomonisch. Sie soll die Webautoren darauf hinweisen, dass UAs diese Angabe gänzlich unterschiedlich und nicht im Sinne von HTTP verarbeiten und dass die Dokumentsprache gefälligst korrekt in html@lang angegeben werden soll.
Gleichzeitig können vorhandene Implementierungen http-equiv="Content-Language" verwenden, um die Sprache von Dokumenten ohne html@lang festzustellen (so war es ja auch halbwegs in HTML 4.01 spezifiziert). Insofern ist http-equiv="Content-Language" nun »deprecated« (auch wenn es den Begriff in HTML5 nicht gibt): Es wird von einem HTML-Parser in der verbreiteten Weise verstanden, ist aber nicht konform.
Die I18n WG hat sich im Übrigen damit einverstanden erklärt:
»It really is a requirement that HTML5 clearly specify if (and if so, how the) HTTP Content-Language and/or the Content-Language pragma is assigned to html@lang when html@lang is itself not present. The I18N WG could accept language specifying the assignment of the (unmodified) Content-Language syntax header/pragma to html@lang, as long as such an assignment were completely unambiguous, although we really would prefer that no such linkage is created.«
Wie offensichtlich geworden sein sollte, soll mit dieser Enscheidung nicht den Webautoren eine Möglichkeit genommen werden, Metadaten auszudrücken. Wäre http-equiv="Content-Language" bloß eine harmlose Meta-Angabe, deren Verwendung keinerlei negative Folgen hätte, bestünde tatsächlich kein Grund zum Handeln. Das ist aber nicht der Fall. Das wusste ich auch nicht und habe mich daher nur zu der Sinnhaftigkeit der Angabe der Sprache des Zielpublikums ausgelassen. Diese Bedeutung hat http-equiv="Content-Language" in der Praxis aber nicht, was mir nicht bekannt war.
Und ich hab auch gerade keine Lust … nachzusehen, wie sich ein HTML5-Parser verhalten soll, wenn er doch auf verbotenes
<meta http-equiv="Content-Language" content="de">stößt.
Ein einfaches Strg + F »Content-Language« über die Spec oder die WG Decisions wäre natürlich auch zu schwierig gewesen.
Fürs Protokoll:
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-meta-http-equiv-content-language
vgl. auch http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#attr-lang
Kurz gesagt:
Ist kein html@lang angegeben und enthält http-equiv="Content-Language" einen einzigen Language-Tag, so verwende diesen als Dokumentsprache.
Also das, was viele UAs derzeit tun, was viele Webautoren bisher erwartet haben und worauf viele existierende Dokumente vertrauen. Aber: Da die verbreitete Verwendung inkonsistent mit der Definition von Content-Language in HTTP ist und die Verarbeitung durch UAs inkonsistent ist, ist es nun nicht konform, die Angabe zu machen.
Mathias
Gunnar Bittersmann