Last modified: 2014-05-01 20:00:38 UTC
1) Bad value X-UA-Compatible for attribute http-equiv on element meta.", 2) link rel="edit" should be an absolute URL. Bad value edit for attribute rel on element link: Not an absolute URL. The string edit is not a registered keyword or absolute URL. The markup causing these issues is as follows: <link rel="edit" title="Edit" href="/w/index.php?title=W3CValidationTest&action=edit" /> <meta http-equiv="X-UA-Compatible" content="IE=EDGE" /> These should at the very least be moved out of OutputPage into the skin or be configurable via OutputPage->setProperty. The mobile skin has no need for the X-UA-Compatible meta tag and wishes to use HTML Validation tests as part of its continuous integration testing to catch problems such as unclosed tags. On a side note: headElement should do with a massive refactor and imo should probably be part of Skin.php so that it can be tweaked where necessary.
*** Bug 62886 has been marked as a duplicate of this bug. ***
For 1: You assume that people never press the compatibility mode button in IE.. See bug: 25378 But, using an http header is an alternative. And headers work in Intranets where meta tags don't (because, in intranets, all sites are rendered in quirks mode, regardless of the meta tag, because too many badly broken websites are deployed in intranets for IE devs to trust anything but http traffic apparently.... head -> desk) http://stackoverflow.com/questions/6156639/x-ua-compatible-is-set-to-ie-edge-but-it-still-doesnt-stop-compatibility-mode http://www.validatethis.co.uk/news/fix-bad-value-x-ua-compatible-once-and-for-all/
In mobile there is no compatibility mode and the need for a compatibility mode depends on how the skin is written. A skin should be allowed to decide if it wants to be compatible with IE or not. The mobile skin Minerva doesn't. I like the idea of the HTTP header.
(In reply to Jon from comment #0) > 2) link rel="edit" should be an absolute URL. Bad value edit for attribute > rel on element link: Not an absolute URL. The string edit is not a > registered keyword or absolute URL. I think it has to be an absolute URL or registered. I went ahead and registered it at http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions . It should take effect eventually (I did the same for bug 38630, ResourceLoaderDynamicStyles, and eventually the actual validator was updated accordingly). I'm not sure why meta tags and link rel can be registered, but X-UA-Compatible doesn't work (it's non-standard, but far more widely known than some of these link rel or meta name registrations). If the HTTP header works the same or better, though, that sounds alright. Note, srcset, which we use, is also currently invalid.
It says you also need to request it be added to the validator, which I did at http://bugzilla.validator.nu/show_bug.cgi?id=991 .
(In reply to Matthew Flaschen from comment #5) > It says you also need to request it be added to the validator, which I did > at http://bugzilla.validator.nu/show_bug.cgi?id=991 . Fixed. The only remaining <meta> one is: <meta http-equiv="X-UA-Compatible" content="IE=EDGE" />
Shall we use TheDjs header technique?
Change 127818 had a related patch set uploaded by Mattflaschen: Change X-UA-Compatible from <meta> tag to HTTP header https://gerrit.wikimedia.org/r/127818
Change 127818 merged by jenkins-bot: Change X-UA-Compatible from <meta> tag to HTTP header https://gerrit.wikimedia.org/r/127818
To confirm, http://validator.w3.org/check?uri=https://www.mediawiki.org/wiki/Project:Sandbox now passes (when the sandbox is blank at least). :) There are still errors on other pages (e.g. http://validator.w3.org/check?uri=https://www.mediawiki.org/wiki/MediaWiki), due to srcset, and page-specific problems. However, this shows the HTML skeleton itself is now passing.
