W3C home > Mailing lists > Public > www-international@w3.org > April to June 2010

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 07 May 2010 13:30:06 +0200
Message-ID: <4BE3F9BE.7080702@gmx.de>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
CC: "public-html@w3.org" <public-html@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>, www-international@w3.org
On 07.05.2010 13:19, Lachlan Hunt wrote:
> It's not at all clear what you mean by "leave it alone", and I'm not
> sure what relevance HTML4 has in this context. Do you mean to leave it
> as is in the current HTML5 spec (option #2)? Or do you mean to define it
> as it was defined in HTML4: provide a vague hint about permitting any
> HTTP header field to be used in http-equiv without defining the
> permitted content attribute values or processing requirements?

I mean the latter. The content is defined in RFC 2616, Section 14.12. 
The processing is defined in HTML 4, Section 7.4.4.

> Given the clear explanation I gave for why even #3 is not a reasonable
> solution, why would that be any more acceptable? What use case would it
> address and or what problem would it actually solve?

The simple answer remains: http-equiv is not for the final recipient 
(the browser), so HTML5 shouldn't define any specific processing other 
the one that's already in HTML4, and not violate layers by inventing new 
format constraints.

Best regards, Julian

PS: what *would* be interesting is to clarify how to treat multiple 
instances of http-equiv; but that's generic to meta/@http-equiv, not 
this issue.
Received on Friday, 7 May 2010 11:30:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 7 May 2010 11:30:47 GMT