W3C home > Mailing lists > Public > public-html@w3.org > August 2008

Re: Are new void elements really a good idea?

From: Robert J Burns <rob@robburns.com>
Date: Sun, 31 Aug 2008 14:34:16 +0300
Cc: "public-html@w3.org" <public-html@w3.org>
Message-Id: <72815CB2-1773-4D96-80A0-740C056A468D@robburns.com>
To: Smylers <Smylers@stripey.com>

Hi Smylers,

On Aug 31, 2008, at 1:53 PM, Smylers wrote:

> Robert J Burns writes:
>> On Aug 30, 2008, at 11:01 PM, Lachlan Hunt wrote:
>>> Julian Reschke wrote:
>>>> there are at least two ways to avoid the problem: ...  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?
>> 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. ... These transitional problems are due to deficiencies  
>> in
>> the text/html  serialization of HTML (... unable to syntactically
>> self-differentiate void from non-void elements like XML can with the
>> <tagname /> syntax).
> Surely "the <tagname /> syntax" is exactly what Lachlan used above?

Yes, Lachlan used that. However, it doesn't imply anything in a  
document transformed to a text/html serialization of HTML5. In XML  
<tagname /> means an element opened and closed. In text/html <tagname / 
 > just means an element opened. When dealing with a DOM structure  
with unknown elements, the serializer can output empty elements as  
<tagname /><nextelement>contents</nextelement> or <tagname></ 
tagname><nextelement>contents</nextelement> , but when deserialized  
from text/html, that's the equivalent of:

           #text:  contents


        #text:  contents

depending on which syntax is used (unless we stop insisting on the  
solidus being a talisman).

However, at least for some legacy UA support, Julians approach  
improves things. For example using <evensource></eventsource> in  
Opera, WebKit and Gecko will at least not lead the nextelement to be  
inside the eventsource element. However, in Gecko any unknown element  
would still implicitly close the paragraph element (is on is on the  
list of open elements).

Take care,
Received on Sunday, 31 August 2008 11:34:56 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:37 UTC