Re: Are new void elements really a good idea?

Hi Julian,

On Aug 31, 2008, at 2:34 PM, Julian Reschke wrote:

>
> Anne van Kesteren wrote:
>> On Sun, 31 Aug 2008 13:22:14 +0200, Julian Reschke <julian.reschke@gmx.de 
>> > wrote:
>>> On the other hand, what, except ideological reasons, stops us from  
>>> allowing
>>>
>>>  <tagname></tagname>
>>>
>>> as well?
>> <br></br> "means" <br><br> due to legacy parsing.
>
> Does that apply to new elements as well?
>
> If that's the case, I would argue that we really shouldn't add new  
> void elements to avoid exactly that kind of confusion.
>

Adding new elements of any kind (void, block or inline) has problems  
(see the wiki [1][2][3]). In IE for example, the non-void elements are  
processed as two consecutive void elements (on with a solidus "/" in  
its name) with a sibling text node in between (the one that should be  
an only child text node of the element).  Attributes on the other hand  
can be handled easily without causing DOM, serialization or  
deserialization issues. Many WG members in the past have been shouted  
down for proposing new elements for these very same legacy issues  
(lack of graceful degradation). Yet we have several poorly conceived  
elements currently in the HTML5 draft (e.g.: header, footer, nav)[4]  
that do not really add anything useful to the semantics of HTML yet  
have these same legacy (poor graceful degradation) issues. Most of  
semantics of these elements would be better introduced through new  
attributes.

Mechanisms like eventsource and source might be necessary and suitable  
as elements, though even these could be handled through attributes  
(e.g., an attribute taking a space separated list of URI references  
for source).

Focussing on more graceful degradation for HTML5 while also amending  
the parsing algorithm to support solidus notation for void elements  
(or any empty self-closing element) for the future would be the best  
way for this WG to go.

Take care,
Rob

[1]: <http://esw.w3.org/topic/HTML/ThoughtExperimentInGracefulDegradation 
 >
[2]: <http://esw.w3.org/topic/HTML/InterimLegacyBridgingMarkup>
[3]: <http://esw.w3.org/topic/HTML/InterimLegacyBridgingMarkup>
[4]: <http://esw.w3.org/topic/HTML/MetadataContainerConfusion>