21207 2013-03-07 05:01:09 +0000 X-UA-Compatible should be recognized for <meta http-equiv=...> 2015-06-17 03:17:00 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified Macintosh MacOS X RESOLVED FIXED P3 editorial --- 1 davidfstr+w3cbugs robin davidfstr+w3cbugs hsivonen julian.reschke mathias mike public-html-admin public-html-wg-issue-tracking robin public-html-bugzilla oldest_to_newest 84061 0 davidfstr+w3cbugs 2013-03-07 05:01:09 +0000 === 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 84065 1 julian.reschke 2013-03-07 08:45:27 +0000 "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? 84168 2 davidfstr+w3cbugs 2013-03-09 04:16:41 +0000 > 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=...>? 84229 3 hsivonen 2013-03-11 15:30:02 +0000 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. 84323 4 davidfstr+w3cbugs 2013-03-13 01:44:20 +0000 > 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. 85046 5 davidfstr+w3cbugs 2013-03-27 04:22:01 +0000 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? 85048 6 julian.reschke 2013-03-27 06:59:36 +0000 (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. 85050 7 robin 2013-03-27 08:42:32 +0000 (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! 121155 8 mike 2015-06-17 03:16:01 +0000 Already fixed. http://www.w3.org/html/wg/drafts/html/master/semantics.html#attr-meta-http-equiv