This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
=== Background === The X-UA-Compatible is an HTTP header used to control the rendering mode of Internet Explorer and the Google Chrome Frame plugin. It is commonly included in HTML directly via something like the following (taken from twitter.com): <meta http-equiv="X-UA-Compatible" content="IE=9,chrome=1"> As currently defined, <meta> does not permit "X-UA-Compatible" as a valid value in the table §4.2.5.3 "Pragma directives", nor does it permit it through §4.2.5.4 "Other pragma directives". This means that web pages using this header will fail validation by the W3C Validator. Maintainer Ville Skytt of the validator indicates in W3C bug 11954 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=11954> that this will not be fixes unless the HTML5 specification is updated to allow this attribute. Suggested options for revision: (A) Permit any value for <meta http-equiv="X" ...>. But only define the semantics of those values explicitly listed in §4.2.5.4 "Other pragma directives". (B) Permit any value for <meta http-equiv="X" ...> that begins with a "X-" prefix, indicating that it is a non-standard header. Interpreters of HTML5 are explicitly not required to handle such experimental attributes and should ignore those that are not understood. (C) Permit "X-UA-Compatible" as an explicit value for <meta http-equiv="X" ...>. However I personally don't think "X-UA-Compatible" requires this kind of special treatment. (D) Surprise me. === References === (0) §4.2.5.3 Pragma directives http://www.w3.org/TR/html5/document-metadata.html#attr-meta-http-equiv (1) X-UA-Compatible Specification http://msdn.microsoft.com/en-us/library/jj676915(v=vs.85).aspx (2) "chrome=1" in X-UA-Compatible for Google Chrome Frame http://www.chromium.org/developers/how-tos/chrome-frame-getting-started/chrome-frame-faq
"4.2.5.4 Other pragma directives Extensions to the predefined set of pragma directives may, under certain conditions, be registered in the WHATWG Wiki PragmaExtensions page. [WHATWGWIKI] Such extensions must use a name that is identical to an HTTP header registered in the Permanent Message Header Field Registry, and must have behavior identical to that described for the HTTP header. [IANAPERMHEADERS]" That's pretty clear, isn't it?
> That's pretty clear, isn't it? I'm not sure what you mean. X-UA-Compatible is not presently in the Permanent Message Header Field Registry and therefore is not permitted as valid by §4.2.5.4 "Other pragma directives". Are you requiring that I get X-UA-Compatible added to the Permanent Message Header Field Registry before you consider making it a legal enumerated value in <meta http-equiv=...>?
I strongly oppose to making the IE=9 bit valid. Having sites activate a particular set of legacy behavior in a particular product is antithetical to the interoperability purpose of the HTML spec. I am less opposed to making IE=Edge valid, though I still think it's bad to make browser-specific markup valid.
> I strongly oppose to making the IE=9 bit valid. > I am less opposed to making IE=Edge valid My thought here: Both are valid values for the X-UA-Compatible header, as defined by Microsft's specification. Not recognizing the full set of valid values would be confusing. I agree that the IE=edge is the less brittle use case. I use it on my own site to force IE to force standards mode (not compatibilty mode) when external code (ex: Disqus) inserts HTML that IE doesn't understand. Actually it's not clear to me that you need to parse the header value here at all. Since it is an X- attribute, it could be stated that this is an implementation-defined pragma. Browsers that do not recognize the header should simply ignore it.
What do I need to do to move this bug forward? * Do I need to get signoff from a particular set of people? (In which case I will invite them to the discussion.) * Should I bring this up as a discussion topic on a particular mailing list? * Or is there another preferred process in this community?
(In reply to comment #2) > > That's pretty clear, isn't it? > > I'm not sure what you mean. X-UA-Compatible is not presently in the > Permanent Message Header Field Registry and therefore is not permitted as > valid by §4.2.5.4 "Other pragma directives". > > Are you requiring that I get X-UA-Compatible added to the Permanent Message > Header Field Registry before you consider making it a legal enumerated value > in <meta http-equiv=...>? Yes.
(In reply to comment #5) > What do I need to do to move this bug forward? > > * Do I need to get signoff from a particular set of people? (In which case I > will invite them to the discussion.) > * Should I bring this up as a discussion topic on a particular mailing list? > * Or is there another preferred process in this community? Given that there does not seem to be intensive discussion in the bug, and that there is disagreement, I would recommend taking it to public-html yes. Thanks!
Already fixed. http://www.w3.org/html/wg/drafts/html/master/semantics.html#attr-meta-http-equiv