Re: ISSUE-88 - Change proposal (new update)

On 05/07/2010 02:34 AM, Lachlan Hunt wrote:
> On 2010-05-05 20:22, Leif Halvard Silli wrote:
>> Let multiple language tags continue to be legal.
>> (http://www.w3.org/html/wg/wiki/ChangeProposals/ContentLanguages)
>
> This is a response to the arguments put forth in both that change
> proposal, the the change proposal from the i18n WG. Both proposals
> present similarly flawed arguments, and so I will refute them together.
>
> http://www.w3.org/International/wiki/Htmlissue88
>
> For this issue, we have 3 options presented:
>
> 1. Make Content-Language non-conforming.
> 2. Leave Content-Language as Obsolete but Conforming, permitting only a
> single language tag. (Current spec)
> 3. Leave Content-Language as Obsolete but Conforming, permitting a comma
> separated list of language tags.

Four. Leif's proposal <http://www.w3.org/html/wg/wiki/ChangeProposals/ContentLanguages>
would be
   4. Leave Content-Language in both HTTP and http-equiv as conforming
      under its defined in HTTP (RFC2616). Make fallback use of
      Content-Language in place of lang="" non-conforming for authors.

Please see
   http://lists.w3.org/Archives/Public/public-html/2010May/0079.html
for an alternative set of proposed spec text which, hopefully, should
be more clear in expressing that intention, even though it is still
somewhat incomplete.

> What real benefit do authors themselves gain from using multiple language values?

Whether Content-Language is useful or useless is not HTML5's concern.
Content-Language is defined in the HTTP spec. HTML5 can, and does,
define *additional* processing that uses the metadata in the HTTP header.
But it is out-of-scope for it to restrict or redefine Content-Language's
syntax or semantics.

The <meta http-equiv> construction is intended to allow the declaration
of HTTP headers inside an HTML document, to allow the embedding of such
metadata within the document. This has the benefit of carrying the
metadata with the content, so that it does not get lost when transferred
among systems and so that it is available in non-HTTP environments.

It makes sense for HTML5 to define which HTTP headers are allowed to be
declared this way and which are not. I can see HTML5 being justified in
removing the ability to specify Content-Language via http-equiv. I don't
see HTML5 as being justified in defining its syntax or semantics to be
different from that given in HTTP.

>> 3. More correct: the difference between @lang and Content-Language is
>> pointed out, while the link between @http-equiv and HTTP is emphasized.
>
> Wrong again, for reasons explained above.

Given that the proposal is to define http-equiv="Content-Language"
in terms of the Content-Language HTTP header and to remove all text
in HTML5 spec that treats them differently apart from their precedence
amongst each other, your reasons "explained above" are not relevant.

> The warning from the validator could be phrased in any way the
> implementer likes. If the lang attribute is detected, the validator
> could simply state that the Content-Language is unnecessary. Otherwise,
> the validator could advise to use the lang attribute instead. But this
> an implementation decison and no spec change is needed to attain the
> desired behaviour in this particular case.

The Content-Language header is not the same as the lang="" attribute.
They serve different purposes and are not redundant. It just so happens
that there's a high correlation in their values, so the HTML5 spec
defines Content-Language as a place to find a fallback value for the
language attribute when none is given. Leif suggests that validators
provide a warning when this happens, so that authors know they should
have set the lang="" attribute if their intention was to set the content
language rather than the audience language.

~fantasai

Received on Monday, 10 May 2010 19:09:11 UTC