- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 04 Jan 2011 15:02:44 +0100
- To: Henri Sivonen <hsivonen@iki.fi>
- CC: public-html-xml@w3.org
On 04.01.2011 14:07, Henri Sivonen wrote: > ... > On Dec 22, 2010, at 03:36, John Cowan wrote: > >> There is a similar problem within HTML itself. Since there is a standard >> way of handling unknown tags to which all HTML5 browsers must conform, >> then either: >> >> 1) All future HTML tags must be processed in the same way as unknown >> tags, or >> >> 2) Some HTML.next documents will have different DOMs in HTML5 and >> HTML.next browsers (thus discarding backward compatibility), or >> >> 3) There will be no future HTML tags, ever. >> >> It's not clear to me which arm of this trichotomy the WG will accept. > > This is a bit of a dirty open secret of HTML5. We pretend in rhetoric that #1 is true, but in practice, if you consider elements introduced by HTML5 and how they behaved in pre-HTML5 browsers, #2 is true. > > Note that this doesn't merely include the set of void elements. It also includes the set of tags that auto-close the p element. In practice, #3 can be relaxed to "There will be no future void elements ever nor elements that are meant to contain paragraphs but aren't meant to be contained in paragraphs." > ... Henri, thanks for that explanation (seriously!). > ... >> 1) RSS2.0 documents are notorious for being "unparseable" within XML. > > It seems that when an XML vocabulary becomes popular among people who aren't XML experts, stuff becomes unparseable as true XML. Not a great sign of success for XML's Draconian policy and the theory behind it. An other point of view is that is becomes unparseable when you can get away with it, that is, if "most" popular clients accept it. See Atom as compared to RSS. Best regards, Julian
Received on Tuesday, 4 January 2011 15:35:41 UTC