2008/12/17 Ian Hickson <span dir="ltr"><ian@hixie.ch></span> <div class="Ih2E3d"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
XML is neither more performant nor stricter than XML. The main differences<br></div>
are that XML has less user-friendly error recovery and supports arbitrary<br>
namespaces. Authors have clearly indicated that this is not compelling.<br>
Deprecating HTML thus seems like vain effort. (We already tried over the<br>
past few years with XHTML 1.x, and it didn't work.)<br>
<div><div><br>
</div></div></blockquote></div><p>I don't write browser code, honestly, but I think that XML parser don't need to check for attribute types (they're all quoted strings), don't check for element type (whether there can or must be closing tag), don't check for insertion modes, just parses the input completely any semantic or particular behaviour associated with any tag. Then, when the DOMElement or DOMAttr or DOM-whatever are built, they get the appropriate interface (eg. HTMLElement) depending on the namespace.<br>
</p><p>I think that the latter algorithm can be faster, but I actually haven't got any benchmark (I cannot have, since no browser implements completely HTML5 parse algorithm yet).</p><p>Secondly, stricter to me means: every warning is an error. Look in the following code:<br>
<div><p>some text</div><br>When the HTML parser find char 'd', i can imagine it expects char 'p' (as in </p>) and fallback to "quirk mode" otherwise, although no assertion are made in the official HTML spec.<br>
When parsing as XML, though, the parser can simply get the char: is it a 'p'? then go forward, else stop parsing<br>no quirks, no trying to guess author intentions</p><p>what about <div><p>some text<p>some more text</div>?<br>
is it this: <div><p>some text</p><p>some more text</p></div><br>or either this: <div><p>some text<p>some more text</p></p></div><br></p><p>And most of time strict checking means less errors caused by distraction (misspelling of an end tag, missing '/' when self-closing elements not always selfclosing, etc.)</p>
<p>Lastly, you said that deprecating HTML is vain. Well, IMO, if you deprecate it now, maybe this year, or next year, or even the year after, nothing will move. But (according to WHATWG Wiki) HTML spec will be ready in 2020.</p>
<p>Do you think that in 12 years everybody will just ignore the string "HTML is deprecated and should no longer be used"?</p><p>By the way, XHTML1.0 / 1.1 said nothing about HTML4, they were independent specifications.</p>
<p>Giovanni Campagna</p>
<br>