Project Cerbera > Life of Ben (Blog) > 2007 > May > XHTML < HTML
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.