- From: Jukka K. Korpela <jkorpela@cs.tut.fi>
- Date: Sun, 11 Apr 2004 02:16:59 +0300 (EEST)
- To: www-style@w3.org
- Cc: www-html@w3.org
(I'm Cc'ing this to the HTML list, since this seems to have turned into a discussion about <meta> tags in HTML rather than CSS issues. It might be best to continue this part of the discussion in the HTML list only.) On Sat, 10 Apr 2004, Boris Zbarsky wrote: > As Ian says, the HTML specification disagrees with > every single HTML implementation on what it is <meta> tags do. > According to the spec, UAs should ignore them altogether. Please cite a specific clause that says so. I don't think there's any. The HTML 4 specification contains statements about servers processing meta tags, and this was not a reality when they were written, still less nowadays. So this should of course be fixed. But the specification does not tell UAs to ignore <meta> tags. It says: "User agents are not required to support meta data mechanisms. For those that choose to support meta data, this specification does not define how meta data should be interpreted." Of course, this makes the meta tag concept very fuzzy. (Incidentally, when checking this, I noticed: In this example, the author's name is declared to be French: <META name="Author" lang="fr" content="Arnaud Le Hors"> which seems to say rather clearly that people's proper names do belong to some language. Hence, W3C pages, including WAI pages, virtually all violate Priority 1 requirement in WAI recommendations, which say that all changes in language be indicated in markup. As the first aid, the icons claiming WAI conformance should be removed, which would set a good example anyway. But I digress.) The XHTML 2.0 draft isn't really more exact in semantics. Actually, it is more vague and very sketchy. It seems to have dropped the http-equiv idea completely. But such moves won't remove the problems. On the other hand, by the time XHTML 2.0 gets defined and implemented, UA's might become clever enough to save information about encoding when creating a local copy of a document. (Lack of such functionality is currently one of the main reasons of using <meta> to specify charset even when you _can_ make the server send correct headers.) > > I can't find anything to indicate one way or the other, but > > what would happen if one were to change > > <meta http-equiv="Content-Type" > > content="text/html; charset=iso-8859-1"> > > to: > > <meta http-equiv="Content-Type" > > content="text/html;charset=iso-8859-2"> > > via the DOM? > > I'm almost certain that nothing whatsoever would happen in current UAs. Then you should check it. It actually changes the UA behavior, _if_ no charset is declared in actual HTTP headers. And this is what the specification explicitly requires: To sum up, conforming user agents must observe the following priorities when determining a document's character encoding (from highest priority to lowest): 1. An HTTP "charset" parameter in a "Content-Type" field. 2. A META declaration with "http-equiv" set to "Content-Type" and a value set for "charset". 3. The charset attribute set on an element that designates an external resource. http://www.w3.org/TR/html4/charset.html#h-5.2.2 (so the spec is self-contradictory, since there's the above-mentioned general statement too - the spec both says it does not define <meta> semantics and actually defines it in some cases). (Item 3 has probably not been implemented in UAs at all. Otherwise, they seem to get this right.) -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
Received on Saturday, 10 April 2004 19:17:01 UTC