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

Re: Are new void elements really a good idea?[1]

From: Robert J Burns <rob@robburns.com>
Date: Sat, 30 Aug 2008 23:13:42 +0300
Message-Id: <62843220-3D77-4439-B371-28F1381E5A65@robburns.com>
To: HTML WG <public-html@w3.org>

Hi Julian,

The problem you raise here is much related to one I raised on  
bugzilla[2] and the wiki earlier[3]. My hope is that since we are  
specifying a parsing algorithm which is currently supported by about  
one current UA, that we specify a parsing algorithm that is more  
forward looking. It won't help us in specifying HTML5, but it might  
help those in this position in the future specifying HTML6.

On Aug 30, 2008, at 9:24 PM, Julian Reschke wrote:

> Furthermore, what's the expectation for future iterations of HTML5, or
> HTML6? Will there be more void elements, again requiring changes in
> existing producers?
> 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>
> instead of
>  <eventsource source="foo">

That sounds reasonable as a transitional syntax. Another bug[4] and  
wiki page[5] provided a fairly comprehensive list of approaches that  
would target transitional support for existing browsers and other UAs.  
Especially for things like using a single cell table for a figure  
rather than a figure, would gain immediate support for caption-side  
CSS styling in existing CSS UAs. However, more importantly is that  
such interim transitional element and attribute definitions would  
allow HTML5 to be deserialized properly into a correct DOM tree (even  
in text/html in existing and legacy browsers).

One suggestion raised on bugzilla was for HTML5 to introduce the '/'  
syntax from XML, but in HTML5 (and beyond) it would mean specifically  
a void element and should not be used to mean an empty non-void element.

Other suggestions related to:
 parsing the head in a way that would support future non-void  
elements and other unknown elements
 adding and in-span insertion mode
 treat unknown elements as inline elements (so as not to force an  
implicit p)

The editor was able to perform extensive research and logic in a  
matter of minutes and rejected the proposal as a wontfix.

Take care,

[1]: <http://lists.w3.org/Archives/Public/public-html/2008Aug/0930.html>
[2]: <http://www.w3.org/Bugs/Public/show_bug.cgi?id=5752>
[3]: <http://esw.w3.org/topic/HTML/ParsingSpecifiedForFutureUpdates>
[4]: <http://esw.w3.org/topic/HTML/ParsingSpecifiedForFutureUpdates>
[5]: <http://esw.w3.org/topic/HTML/InterimLegacyBridgingMarkup>
Received on Saturday, 30 August 2008 20:14:34 UTC

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