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

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
http://lachy.id.au/
http://www.opera.com/

Received on Friday, 7 May 2010 11:58:13 UTC