W3C home > Mailing lists > Public > www-validator@w3.org > February 2010

Re: Valid use of <embed> in HTML4

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Fri, 5 Feb 2010 22:30:09 +0100
To: www-validator@w3.org
Message-ID: <20100205223009569770.42ada6cd@xn--mlform-iua.no>
Michael A. Peters, Fri, 05 Feb 2010 11:44:28 -0800:
> Shane McCarron wrote:
>> David Dorward wrote:
>>> Good luck with testing in every version of every browser out there.
>>> Write code to the standard. Test common browsers to make sure that 
>>> their bugs don't break the site. Don't give browsers you aren't 
>>> testing something that *shouldn't* work.
>> Amen brother!

To write SGML comments _is_ to "write code to the standard", though. 
And exploitation of browser bugs is a trade of the business. 

The accepted way to target IE browsers is to use the proprietary 
conditional comments for instance. To be consistent, you should warn 
against using conditional comments also - as it isn't "to the standard".

Also, ironically, the use of conditional comments, depends on heavy 
testing of what IE support and not - good look with that! 

It also leads to very confusing CSS authoring practise - it is harder 
to operate with several style sheets than just the same one(s) for all 

> I looked at that solution and it looked to me like it exploited a bug 
> in browsers, the embed tag should not have been rendered because it 
> is in a cdata block.

Well, although this is technically true, it is not true in practise. 
The real exploitation is the use of the '</>' tag. It is that, 
unsupported, tag which closes the <script> so that the CDATA section 
can start.

User Agents do have some support for <![CDATA[ ]]> - but not inside 
(what they perceive as) the <script> element. HTML4 doesn't look for 
CDATA inside SCRIPT - the only thing it looks for there is end tags.

> If you are going to use a non standard tag and still want validating 
> content, better options exist. In order of my preference:
> 1) In this case, declare an html 5 doctype.

The HTML5 master plan is that HTML5 parsing rules will apply to any 
kind of HTML, including HTML4, so (A) it is presumably safer and safer 
to use this loop hole, (B) it cannot be considered a "bug in browsers" 
if browsers are consciously made to behave that way.


> 2) Write a custom DTD that supports your tag

May be a good idea, but the message from W3C is mixed: 

> 3) Use JavaScript to insert your tag upon on pageload (not ideal but 
> better than an ugly hackish looking thing that involves script node 
> and cdata block)

Well, then you must be sure to escape end tags within the script 
element - avoiding that need was one of the problems I was trying to 
get rid of ...

Of course, a new DTD for HTML4 which redefined HTML4's hopeless rules 
for the SCRIPT element, would help a lot ... (Well, it would not 
specifically help the <embed> case - but I actually not a <embed> fan - 
on the contrary.)

Since you favour HTML5 so much, what would you do there? It doesn't 
support DTD. Or any other extensibility - except the "write your own 
spec" kind of extensibility.
> Note that using a script node like that may invoke some of the 
> various client side XSS filters. To get legitimate stuff past those 
> filters, it is best to be as straight forward as you can and not 
> write something that looks like it is trying to do something funny.

This is of course good to be aware of.
leif halvard sili
Received on Friday, 5 February 2010 21:30:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 14:18:00 UTC