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

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.

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.

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.

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

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.

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.

-- 
regards, Kornel Lesiński

Received on Saturday, 3 April 2010 01:31:04 UTC