This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We should update the spec to deal with the reality of meta@http-equiv=x-ua-compatible I propose just adding it to the list of defined keywords at https://html.spec.whatwg.org/multipage/semantics.html#pragma-directives as a conforming value. An alternative is to change the requirements in the https://html.spec.whatwg.org/multipage/semantics.html#other-pragma-directives section to say something like: "Such extensions must use a name that is identical to an HTTP header that is registered in the Permanent Message Header Field Registry **or that is defined in a specification which provides a detailed description of the its semantics and requirements**,..." A specification of the semantics and requirements of "x-ua-compatible" is at http://msdn.microsoft.com/en-us/library/ff955275%28v=vs.85%29.aspx See also the discussion at https://wiki.whatwg.org/wiki/Talk:PragmaExtensions
*** Bug 27071 has been marked as a duplicate of this bug. ***
FYI for now I changed the behavior in the validator sources such that meta[http-equiv=x-ua-compatible] no longer causes an error to be emitted if there's an accompanying content=IE=edge (case-insensitive). Any other value for the content attribute causes an error to be emitted saying, "A meta element with an http-equiv attribute whose value is X-UA-Compatible must have a content attribute with the value IE=edge."
Checked in as WHATWG revision r8870. Check-in comment: With great reluctance, admit X-UA-Compatible exists. https://html5.org/tools/web-apps-tracker?from=8869&to=8870