- From: Robert J Burns <rob@robburns.com>
- Date: Sat, 30 Aug 2008 23:13:42 +0300
- 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, Rob [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