W3C home > Mailing lists > Public > www-html@w3.org > April 2004

Re: Behavior of <meta> elements linking in stylesheets

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
Message-ID: <Pine.GSO.4.58.0404110155160.23899@korppi.cs.tut.fi>

(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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:16:00 GMT