27091 2014-10-17 09:33:01 +0000 deal with the reality of meta@http-equiv=x-ua-compatible 2014-12-03 21:48:53 +0000 1 1 1 Unclassified WHATWG HTML unspecified PC All RESOLVED FIXED P2 normal Unsorted 1 mike ian contributor ian mike w3bugs contributor oldest_to_newest 113377 0 mike 2014-10-17 09:33:01 +0000 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 113405 1 ian 2014-10-17 23:45:33 +0000 *** Bug 27071 has been marked as a duplicate of this bug. *** 114583 2 mike 2014-11-06 03:14:05 +0000 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." 115872 3 contributor 2014-12-03 21:48:53 +0000 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