[whatwg] X-UA-Compatible, X-* headers, validators, etc.

[Alex Russell]

On Wed, Oct 7, 2009 at 11:20 AM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> On Wed, Oct 7, 2009 at 2:01 PM, Alex Russell <slightlyoff at chromium.org> wrote:
>> we'd like to request
>> that an exception be made to the "registered via RFC" rule for
>> http-equiv headers which are prefixed with "X-", or, alternately, that
>> the spec simply declare that unlisted keys and values will not be
>> considered invalid, but rather that only invalid values for listed
>> keys trigger validity errors.
>
> This seems to conflict with:
>
> "Vendor-specific proprietary extensions to this specification are
> strongly discouraged. Documents must not use such extensions, as doing
> so reduces interoperability and fragments the user base, allowing only
> users of specific user agents to access the content in question.

Ignoring for the moment the "spirit of the law" discussion, this isn't
a vendor-specific extension, it's a request that HTTP headers and they
exist in the real world (in a pervasive way) are adequately
representable in the existing markup semantic designed to do *exactly
that*. The Pragmas extension wiki page indicates intent to forge
real-world compatibility. The request is only for a means to do so
adequately.

Regards

> "If vendor-specific markup extensions are needed, they should be done
> using XML, with elements or attributes from custom namespaces. If such
> DOM extensions are needed, the members should be prefixed by
> vendor-specific strings to prevent clashes with future versions of
> this specification. Extensions must be defined so that the use of
> extensions neither contradicts nor causes the non-conformance of
> functionality defined in the specification.
>
> ...
>
> "When vendor-neutral extensions to this specification are needed,
> either this specification can be updated accordingly, or an extension
> specification can be written that overrides the requirements in this
> specification. When someone applying this specification to their
> activities decides that they will recognise the requirements of such
> an extension specification, it becomes an applicable specification for
> the purposes of conformance requirements in this specification."
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#extensibility>
>
> All vendor-specific extensions are prohibited, not just for http-equiv.
>