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

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

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Fri, 07 May 2010 13:57:41 +0200
Message-ID: <4BE40035.60107@lachy.id.au>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: "public-html@w3.org" <public-html@w3.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>, www-international@w3.org
On 2010-05-07 13:30, Julian Reschke wrote:
> 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.

I already demonstrated how HTML4 lacks any real processing requirements 
there there.

>> 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.

The layer violation is in HTML4, where it pretends that an http-equiv 
attribute in the markup intended for the client, is to be used by 
servers.  This has never been the case in practice.  The http-equiv and 
content attributes are used exclusively for client side processing in 
all instances where they are used for anything at all.

This is the case with http-equiv values of Content-Type, 
Content-Language, Default-Style and Refresh.  None of these values, when 
they occur in the meta element, are ever, nor should they ever be, used 
by server side processing.

Lachlan Hunt - Opera Software
Received on Friday, 7 May 2010 11:58:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:40:58 UTC