- From: Leif H Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Wed, 03 Aug 2011 00:06:31 +0300
- To: jkorpela@cs.tut.fi
- Cc: www-validator@w3.org, jfrench@ixley.com
Jukka K. Korpela, Sun, 31 Jul 2011 23:18:05 +0300: > 31.07.2011 18:53, Leif Halvard Silli wrote: >> Jeff French, Sat, 21 May 2011 10:21:42 -0700: >>> I'm not sure why this error comes up. This http-equiv value has been >>> around for at least a few years and seems like it should be valid. >>> >>> Bad value X-UA-Compatible for attribute http-equiv on element meta. >>> <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> >> >> It is not necessary that it is valid, because there is a valid way of >> inserting it, see http://www.w3.org/Bugs/Public/show_bug.cgi?id=12072 > > That discussion seems to revolve around comments before <!doctype>, > though it mentions the X-UA-Compatible issue too. And it's a rather > complicated discussion. (And I can't find a "valid way of inserting > it" there.) Sorry, I did not really mean not to point to that bug (although it *is* relevant). I simply mean to point to the message to this list - where I pointed to that bug ... http://www.w3.org/mid/20110330034421114269.a22bfb58@xn--mlform-iua.no > Meta tags with http-equiv="X-UA-Compatible" are used for various > purposes, such as making some versions of IE behave by the > specifications in some issues or just reasonably. Is X-UA-Compatible meta tags used for any other thing than that specific thing? AFAIK, X-UA-Compatible is only used for IE browsers: Either to trigger a certain "compatibility mode" within IE's native Trident engine. OR to trigger IE to start the ChromeFrame. > For example, some > versions of IE treat an Ascii hyphen "-" as a character that allows > line break before and after it, and the "before" part is just absurd. > The tag > <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"> > seems to cure this, though with some cost. IE=Edge doesn't cure it? > So are you sure that for _all_ issues that can be handled with > X-UA-Compatible, there is an equally or better supported other way? No. See below. > But this isn't really about the validator, this is about the > _specification_ of HTML5. The point I wanted to make (by pointing to that the message - and not to that bug), was that it *is* possible to insert X-UA-Compatible in a HTML5 page, without triggering an error message in the HTML5 validator. In words, this is how you do it: * create an conditional *before* the DOCTYPE * place the X-UA-Compatible meta element inside the cond comment * if the conditional comments targets IE installations that perhaps will not react to your X-UA-COMPATIBLE meta, then you probably also need to place a DOCTYPE inside the cond comment, before the X-UA-COMPATIBLE meta element, to prevent quirksmode. By example, this is how - with a general <!--[if IE]>: <!--[if IE]> <![if lte IE 7]><!DOCTYPE html><![endif]> <meta http-equiv="X-UA-Compatible" content="IE=edge;chrome=1"> <![endif]--> <!DOCTYPE html> <html> By example, targeting IE versions which react to X-UA-COMPATIBLE: <!--[if gte IE 8]> <meta http-equiv="X-UA-Compatible" content="IE=edge;chrome=1"> <![endif]--> <!DOCTYPE html> <html> Why these hoops: X-UA-COMPATIBLE cannot occur inside a coniditional comment - it doesn't work then. But if the conditional comment is placed before the DOCTYPE, then IE moves it into the head element before reparsing it (at least, that is what I think happens). Hence it works anyhow. NB: I have not tested if this trick also works for Chrome Frame. As for HTML5: please file a bug, if you want HTML5 to allow "free use" of the http-equiv element. Personally, I think it is OK that there is no free use in HTML5, though. The X-UA-COMPATIBLE is, from my POV, a vendor specific syntax. As such I'm fine with the fact that one can insert it via the MS vendor specific conditional comments. -- Leif H Silli
Received on Tuesday, 2 August 2011 21:07:38 UTC