XHTML < HTML (30th May 2007)

From #html-wg IRC logs today:

hyatt:all using XHTML gets you is slower parsing, loss of key JS functionality, bugs, and (in some browsers) non-incremental rendering
xover:If you assume the input is “perfect” XHTML, no need to deal with possible author borkage.
mjs:well, XML parsers are already an example of what happens then
mjs:although they do have to detect errors so they can fail
mjs:sometimes detecting errors is more work than just handling them the same as the non-error case
mjs:I don’t think there’s an intrinsic simplicity advantage to either HTML or XML parsing; or performance advantage when dealing with conforming content
xover:Code Complexity then?
mjs:XML has simpler error handling rules (hard failure) but the internal subset and other such things make up for it in added complexity
mjs:in any case the parser is a fairly small part of the implementation, all things considered
mjs:most of the core code is DOM, CSS, JavaScript and layout
mjs:and the parts with the hardest algorithms are JS and rendering/layout
xover* can well imagine... *
mjs:DOM does not have too many fancy algorithms required, but it is a fair chunk of code and requires careful thinking to choose the right data structures
hyatt:the rendering/layout code will put hair on your chest.
hyatt* flexes. *

This shouldn’t be news to you, unless you still believe the hype. The lengthier sytax of XML means it takes a bit longer to GET across the Internet, too.

Monday 17th November 2008

Maciej expands on XML, in particular the amount of code required for it in Webkit. Håkon joins in, detailing how WML played out.

See Also