This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The validator currently returns an error when validating HTML5 documents containing an IE rendering mode meta tag, eg: <!DOCTYPE html> <html> <head> <meta http-equiv="X-UA-Compatible" content="IE=EDGE" /> <meta charset="utf-8" /> <title>I need to be set to EDGE in IE!</title> </head> <body> </body> </html> This tag is required in many production environments and cannot be removed. The effect is that large numbers of HTML5 documents can never pass validation due to this error. This is a substantial barrier to adoption in any environment where code quality checks are required. Although IE's rendering mode can be set using http headers, that solution is not always available and does not work for all scenarios. The meta tag cannot be hidden with IE conditional comments as it no longer functions as required (IE8 will revert to IE7 emulation instead of standards mode). Suggested solutions: 1) Ideally the validator should pass this value for http-equiv, even if it is of dubious origin it is legitimate code in real world development (we don't have to like the tag, but we do have to use it). 2) Failing that, the validator could downgrade the error to a warning; so the document could pass validation checks - go green - while still being functional in IE. 3) Alternatively, the validation report could return a non-error, non-warning note about x-ua-compatible; so that the presence of the tag does not impact validation so long as the tag itself is well-formed. The overall benefit to the advancement of standards is higher by allowing developers to use both HTML5 *and* x-ua-compatible. HTML5's general acceptance of a pragmatic approach - paving the cowpaths - would seem to support a concession to practicality here.
Agreed. X-UA-Compatible meta element is REQUIRED to ensure that IE8+ user cannot accidentally switch to harmful "Compatibility view" mode by accidental pressing appropriate small graphic button in IE GUI. This button gets hidden only when using "X-UA-Compatible" meta element with "IE=edge" value sothat switching gets impossible. If button is not hidden and is pressed by user, IE8/9 switches to operate as old IE7. This makes all the web to stuck with old IE7 rendering and bugs even while users actually use modern IE9. Worse, this IE setting persists between browser sessions, so, once switched to "Compatibility view" mode, the site will ALWAYS work as in IE7 for particular user. Very often, users press the button ACCIDENTALLY, so the button should be hidden anyway for any modern site -- by using X-UA-Compatible meta elements. Returning named HTTP-response server header is not always possible, so the meta element is (and definitely will be) widely used. Moreover, before HTML5, this was not an error. HTML5 authors should not invent such nonsensical limitations. -- More generally -- it's not of HTML spec responsibility AT ALL to dictate what meta elements are allowed and what are not. Meta element should be considered valid if it conforms to general HTML syntax as for tags and attributes, not particular values at all. Meta element should be able to have any name ("name"/"http-equiv" attribute) and any value ("content" attribute). As a last resort, non-standard meta elements should be notices, not errors, during validation. Considering these as errors is just detaching from reality. Such detaching from reality is why XHTML1 has beed superceded with HTML, as well as why XHTML2 has been dropped at all. W3C should not make this mistake again. HTML spec should be free from such redundant harmful limitations. Thanks.
This is not a bug in the validator (nor the validator.nu backend as far as I can tell which is invoked for HTML5 documents). The validator just checks for documents against specifications. If you want something in the HTML5 specification changed, I suggest contacting the W3C HTML Working Group about it: http://www.w3.org/html/wg/ Regarding HTML5 bugs in the validator in general, please see the HTML5 related bug reporting instructions at http://validator.w3.org/feedback.html#bugreport