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

On 03.04.2010 03:30, Kornel Lesinski wrote:
> On Fri, 02 Apr 2010 21:11:40 +0100, Julian Reschke
> <julian.reschke@gmx.de> wrote:
>
>> There is a problem, as long as HTML5 pretends that it can state what
>> is allowed in http-equiv. It's simply not HTML5's business.
>
> It can. It's an HTML attribute, not an HTTP header.

The attribute is an HTML attribute, but it's value space is defined by 
the HTTP header registry.

Changing this in general *will* cause objections (yes, those).

> I agree that difference between http-equiv and HTTP is constant source
> of confusion. Authors mistakenly think it is equivalent of HTTP headers,
> and that most/all HTTP headers would work that way (e.g. there's lots of
> documents with HTTP cache directives in HTML).
>
> Obviously, it's not an HTTP header equivalent (unless HTTP will require
> HTTP clients to parse HTML) – the name is very misleading.

Why would HTTP want to make requirements on HTML processing?

> Although HTML's definition of Content-Language could be aligned with
> HTTP definition, I think there's no point doing so, because that will
> only make the illusion stronger, but won't solve the confusion around
> http-equiv – it's just one tiny issue in sea of problems this attribute
> has.
>
> If we change that one, should we "fix" Content-Type too? I've seen
> confused authors use application/xhtml+xml in <meta> of text/html
> documents.

Yes, there's lots of confusion. The way to address this is to explain 
the problem, and to point out better alternatives. But that doesn't 
require making an incompatible change to HTML4.

> Should we remove Refresh? Or is HTTP going to add it?

"HTTP" doesn't need to add it. It could be added to the HTTP header 
registry, as something which is used in practice, but won't work in 
actual HTTP messages. The IANA registration could point to the relevant 
HTML spec section.

> Because confusion caused by http-equiv is unavoidable, I think the best
> way to resolve it is to discourage its use altogether. Limiting its
> utility is on the right track.
>
> I'm not aware of any contemporary implementations that make use of
> multiple languages in Content-Language pragma, and future
> implementations should use lang attribute instead.

I think we already heard about these use cases. Just because *browsers* 
do not support them doesn't mean that it's not used in other frameworks, 
and there's really no reason to make those documents non-compliant.

> If difference between HTML's Content-Language and HTTP's
> Content-Language is really that much of a problem, I think it should be
> resolved by completely removing Content-Language pragma from HTML.

Yes, being *silent* on this (just like HTML4 was) might be acceptable.

Best regards, Julian

Received on Saturday, 3 April 2010 09:01:22 UTC