W3C home > Mailing lists > Public > www-validator@w3.org > August 2011

Re: [VE][html5] http="X-UA-COMPATIBLE" should be valid

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
Message-ID: <8049756250.996797191@xn--mlform-iua.no>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 25 April 2012 12:14:48 GMT