- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 07 May 2010 13:30:06 +0200
- 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 UTC