- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Wed, 29 Dec 2010 19:22:20 +0100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Ian Hickson <ian@hixie.ch>, Norman Walsh <Norman.Walsh@marklogic.com>, public-html@w3.org
Julian Reschke, Wed, 29 Dec 2010 08:56:35 +0100: > On 28.12.2010 22:39, Ian Hickson wrote: >> ... >> In what sense is there a _growing_ chasm between HTML and XML? HTML today >> is significantly closer to XML than HTML4 was, for example it supports the >> "/" syntax on void elements, it allows xmlns="" talismans, etc. Surely the >> two are in fact closer than ever. Indeed even before the HTMLWG was >> restarted at the W3C, the WHATWG had spent significant efforts in getting >> them as close as possible while maintaining backwards compatibility. >> ... > > One factor here certainly is perception. HTML5 documents a chasm that > was already there. It makes it more clear what the chasm is. > > That being said, it *is* growing partly. For instance, HTML5 didn't > need to add new void elements, and it could have ruled them out for > the future. Regarding <void>: 'chasm' or respect for the HTML system/identy? If you have parsing in mind, how can one say no to void elements in HTML without saying no to <void/> in XHTML as well? Which option would you suggest: 1) Parse <newVoid> as non-void. Parse <newVoid/> and <img> as void. Require authors to use XHTML syntax - '/>'. 2) Parse <newVoid> like <img> is parsed. Require authors to use XHTML syntax: <img/> + <img></img>, <newVoid/> + <newVoid></newVoid> I think HTML5 is currently following the second option, with the exception that <newVoid></newVoid> and <img></img> is not permitted. The reason for not permitting <newVoid></newVoid> and <img></img> is probably the problem related to '</br>'. -- leif halvard silli
Received on Wednesday, 29 December 2010 18:22:57 UTC