- 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