Re: Making the HTML language self-describing

On Thu, 08 Jan 2009 12:45:43 +0900, Ian Hickson <ian@hixie.ch> wrote:

>> > However, DOM differences would be the least of your problems if the UA
>> > doesn't support the void elements.
<X>
>> > In other words, it basically *doesn't matter* if the DOM is different
>> > if you're using void elements the UA doesn't support.

I disagree, Ian. I've tried using User JavaScript to "fix" DOM trees that  
are "wrong" due to parsing differences between browsers, and it was  
surprisingly difficult to re-organise the DOM into something usable again  
(particularly if you have to do it AFTER parsing but BEFORE the script  
tries to use the DOM..)

Also consider the situation if void elements from HTML5 are copied into  
pages that are only tested in HTML4 browsers: the DOMs will likely be  
different, and HTML5 browsers will probably be at a disadvantage.

>> 3. The site could deploy a custom plugin or extension and use that to
>> implement the element.
>
> Such custom plugins or extensions could fix the markup at the same time.

This isn't as easy as it sounds (at least not working after the parsing -  
it might be possible for a Firefox extension or IE BHO to modify markup  
before parsing happens? I don't know, but in such cases what about errors  
introduced for example with document.write()? Does an extension see that  
markup too?).

>> > In fact, as far as I can tell, the only problem would be with
>> > round-tripping, which is a serialisation issue:

Certainly not, the main problems I imagine would be scripting against a  
DOM that is different from what the script expects.

Another potential problem is an unknown void tag's interaction with FORM  
scope - i.e. if you say <form><SomeVoidElement></form><input> - is the  
input a child of a form? (Currently: Firefox and Opera say yes, IE8 and  
Safari no - [1].)

It seems to me that introducing some inconsistency in the way /> is  
handled is a price that might be worth paying for potentially improved  
back- and forward compatibility in parsers.

Jonas already suggested these:
> 2. Allow a trailing '/' to indicate an empty element on all unknown  
> elements.

I'm slightly wary of this because browsers don't currently do it. Hence  
we'd be introducing incompatibility with existing content - but I don't  
know how serious a pain it will be. If we are going to let authors mark  
future void tags as void, "/>" is the absolutely simplest approach so it's  
a tempting idea.

> 3. Make it conforming to write void elements as <foo></foo>. I.e.
> <eventsource></eventsource> would be conforming and equivalent to
> <eventsource>.

I think this would confuse authors more, and be more typing and work for  
them. For better or worse, many people already are familiar with />  
because of the common <br /> and because of XML.


[1]  
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Chtml%3E%3Cform%3E%3CVoidTag%20%2F%3E%3C%2Fform%3E%3Cinput%3E%3C%2Fp%3E%0A%3Cscript%3Eonload%3Dfunction()%7Bw(document.getElementsByTagName('input')%5B0%5D.form)%7D%3C%2Fscript%3E%20

-- 
Hallvord R. M. Steen
Core JavaScript tester, Opera Software
http://www.opera.com/
Opera - simply the best Internet experience

Received on Monday, 12 January 2009 07:54:49 UTC