Re: meta content-language

On Fri, August 22, 2008 9:46 am, Robert J Burns wrote:
>
> Hi Leif,
>
> On Aug 22, 2008, at 1:27 AM, Leif Halvard Silli wrote:
>
>>
>> Phillips, Addison 2008-08-21 22.06:
>>
>>>>> In any case, all of the http-equiv attributes are defined
>>>>> by HTTP. That is its definition in HTML.
>>>> It's not the definition in HTML5 as drafted.
>>> I think the point is that it should be.
>> [...]
>>> I do support having the pragma, but it should have the meaning
>>> defined by RFC 2616 and (normatively) it should be consistent
>>> with the RFCs *and nothing more*. If Frontpage or Vignette or
>>> whatever want to do something useful with the information,
>>> bully for them. But don't set the page processing language by
>>> fiat or change the allowed format/values.
>>
>> So is it your view that not only the HTML 5 draft, but even the HTML
>> 4 spec is wrong on this as well?
>>
>> From HTML 4, Section 8.1.2, Inheritance of language codes:
>>
>> An element inherits language code information according
>> to the following order of precedence (highest to lowest):
>>   * The lang attribute set for the element itself.
>>   * The closest parent element that has the lang attribute
>>     set (i.e., the lang attribute is inherited).
>>   * The HTTP "Content-Language" header (which may be
>>     configured in a server). For example:
>>     Content-Language: en-cockney
>>   * User agent default values and user preferences.
>
> My understanding is that we don't want that order of precedence
> changed. That is we don't want the meta pragma used by UAs when the
> lang attribute is present.
>
> On a slightly separate issue, I think we should make it clear that the
> language code should be the first one in the http Content-Language so
> that if a document has: <meta http-equiv='Content-Language'
> content='en, he'>, it treats and there's no lang attribute, it treats
> it as 'en' (which is I think what the current draft does).
>

Assuming the list is prioritized, which it may not, in which case taking
the first value is no better than taking a random value from the list.

I'd argue that Content-Language should be just metadata, informative and
not part of any language inheritance mechanism.


>
> True, but the other contention (not mine) is that the http-equiv
> pragmas are to be decoupled in HTML5 from their http definitions
> (leaving just their names as a historical artifact). The biggest
> problem I see with that is that we've seen no use cases or problem
> statements to justify such a (potentially very confusing) decoupling.
>

wouldn't that make inheritance a more thorny issue. If there is a HTTP
Response Header and also a meta element which would take precedence? You'd
have to support both in an algorithm.

But then if i were building an application to use metadata about language
in some decisive way, I'm probably not going to use the Content-Language
meta element but rather use a more specific metadata schema.

Just my two cents worth.

-- 
Andrew Cunningham
Research and Development Coordinator
Vicnet
State Library of Victoria
Australia

andrewc@vicnet.net.au

Received on Friday, 22 August 2008 00:14:50 UTC