Re: Null change proposal for ISSUE-88 (mark II): proposed note

On Thu, 8 Apr 2010, Richard Ishida wrote:
> >
> > Another change proposal suggests adding a note on the basis that we 
> > should clarify why the HTTP and pragma declarations are different when 
> > it comes to values, and how they should be used, suggesting that this 
> > is a constant source of confusion.
> 
> The note proposes to clarify why HTTP and pragma declarations are 
> different from lang/xml:lang attribute declarations - not why HTTP and 
> pragma declarations are different from each other.

Oh, I see. That is indeed a different matter. I agree entirely that there 
is confusion on _that_ front; that's why HTML5 requires that HTML5 
validators include a warning whenever validating a document that contains 
the Content-Language pragma, and why the spec says, right at the top of 
the pragma's definition, "Authors are encouraged to use the lang attribute 
instead". I'm happy to add more, but I don't know what more to add. The 
proposed note the change proposal is wrong on several fronts, for example 
it implies that the Content-Language pragma says something about the 
intended audience rather than the document itself, which isn't consistent 
with how the pragma actually works.


> As part of its remit, the i18n WG has talked with many many people over
> several years about how to declare language in HTML documents. In our
> experience over those years, the question as to whether they should use the
> lang attribute or the meta tag with Content-Language (which I will refer to
> as 'the pragma' here) has almost without exception proved confusing to
> content authors. That is the confusion we are concerned about. 

We can make the pragma entirely non-conforming instead of conforming with 
a warning, if that would help. It's only conforming at all because it is 
used by authors and we didn't want to force anyone upgrading to change, 
but if it's causing them as much confusion as you say, then it seems that 
maybe it would be worth it just to reinforce the lesson that people should 
just use lang="".


> We agree with the HTML5 spec [2] that authors should be encouraged to 
> use the lang attribute to declare the default language of the document, 
> and our concern is that changing the syntax of the pragma to accept only 
> a single value makes it appear to be equivalent alternative to the lang 
> attribute and therefore lessens the likelihood that authors will use the 
> attribute - especially for those who don't validate their content and 
> see a warning message.

That does make sense. Would it be acceptable then to just make the pragma 
non-conforming, thus removing any valid syntax at all?


> > Furthermore, the suggested note is wrong in practice. The pragma 
> > doesn't give metadata about the document. The original intent of the 
> > <meta http-equiv> feature was to provide a way for _servers_ to 
> > include data in their HTTP headers on a per-file basis; this isn't 
> > document-wide metadata for user agents, it's for servers.
> 
> The purpose of the HTTP header is described in 14.12 Content-Language of 
> RFC2616 as:
> 
> "The Content-Language entity-header field describes the natural 
> language(s) of the intended audience for the enclosed entity. Note that 
> this might not be equivalent to all the languages used within the 
> entity-body." http://www.ietf.org/rfc/rfc2616.txt
> 
> So I'm not sure why you say that the pragma is not originally designed 
> for metadata about the document, given that you point out that it was 
> originally designed to feed the HTTP header, which is metadata.

HTML4 says http-equiv was intended as a way to control servers. That's not 
metadata (though the result, when using Content-Language with http-equiv, 
is metadata in the HTTP headers). But this might be splitting hairs.


I'll update the change proposal. Thanks for clarifying what was intended.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 8 April 2010 20:37:59 UTC