Re: Are new void elements really a good idea?

Hi Lachlan,

On Aug 30, 2008, at 11:01 PM, Lachlan Hunt wrote:

> Julian Reschke wrote:
>> So, coming to HTML5, why exactly are we introducing new void  
>> elements  such as <eventsource>, knowing that existing code will  
>> need to be updated to produce them? The same way HTML5 tries to  
>> protect existing Web content, it *should* also try to protect  
>> existing code, avoiding totally needless updates.
>
> Authoring tools shouldn't be considered to be immutable.  Like web  
> browsers, they too need to be updated to deal with many new features  
> in HTML5.  Even the parsers in web browsers need to be significantly  
> updated for many reasons, including the parsing of new void elements.

And that fact creates problems for processing HTML5 in legacy  
browsers. The DOM tree will be constructed differently in each of the  
major browsers. This makes the adoption of HTML5 for authors targeting  
legacy (as in now current) browsers less than idea. BTW, see also the  
wiki page: Thought experiment in graceful degradation[1], which was an  
early attempt last year to understand the transitional problems facing  
HTML5.


>> Furthermore, what's the expectation for future iterations of HTML5,  
>> or HTML6? Will there be more void elements, again requiring changes  
>> in existing producers?
>
> It's entirely possible that new void elements could be introduced.   
> But instead of trying to restrict the growth of HTML5 based on the  
> designs of old authoring tools, the authoring tools should also be  
> updated to expect new void elements and be able to deal with them  
> better.

These tool are already aware of void elements. It's not that void  
elements are a surprise. The problem is that any tool has to decide  
how to treat an element it doesn't know. WebKit treats unknown  
elements as non-empty elements (adding the next element first child).  
IE treats unknown elements as void elements (adding the next element  
as a next sibling). Gecko treats unknown elements as block (adding the  
next tag as a first child element, but also implicitly closing the P  
tag if one is on the stack). XSLT appears to follow something like the  
WebKit approach. However, the point is that any UA has to make a  
choice here since there is neither a DTD to inform the UA nor does  
text/html serialization include the information necessary to know  
about the unknown elements (as Julian explained earlier).

>
>
>> As far as I can tell, there are at least two ways to avoid the  
>> problem:
>> 1) Do not introduce new void elements, and state, once for all,  
>> that no new elements will be added beyond those in HTML4.
>> 2) Keep introducing new void elements, but always allow non-void  
>> notation, such as
>> <eventsource source="foo"></eventsource>
>
> <eventsource src="foo"/> is allowed.  Isn't that sufficient?

Sufficient for what? As part of a serialized document that needs to be  
processed  by a UA that does not know what an eventsource element is,  
it is not sufficient. Should it produce a DOM

html
   eventsource
      nextelement

or

html
    eventsource
    nextelement

where next  element can even be a known element.

These transitional problems are due to deficiencies in the text/html  
serialization of HTML (divorced of DTDs and schema in general and  
unable to syntactically self-differentiate void from non-void elements  
like XML can with the <tagname /> syntax). We should make sure we fix  
those problems in specifying this new text/html serialization. and its  
complementary parsing algorithm.

Take care,
Rob

[1]: <http://esw.w3.org/topic/HTML/ThoughtExperimentInGracefulDegradation 
 >

Received on Sunday, 31 August 2008 08:56:23 UTC