Why XHTML?

Recently I had a short discussion in twitter with my web standards guru Molly Holzschlag about XHTML serialisation of HTML5. I was wondering what was the use case for XHTML when HTML serialisation provides everything you just might need. And then she talked to Steven Pemberton, W3C Chair of HTML and Forms Working Groups, results of which conversation Molly publishes here.

Firstly I thought I’d comment to her blog post, but then decided that my readers would be interested in this as well.

I’d like to reply to each statement Steven does.

So, parsing. Everyone has grown up with HTML’s lax parsing and got used to it. It is meant to be user friendly. “Grandma’s mark-up” is what I call it in talks.

I completely agree with the statement that everyone has grown up with HTML’s lax parsing. This implies that making people to switch to other approach (strict parsing), even if it’s for the good, will become quite a significant task.

And it will be impossible to change all the existing pages that were prepared in HTML. This is a backwards compatibility issue of XHTML standard.

But there is an underlying problem that is often swept under the carpet: there is a sort of contract between you and the browser; you supply mark-up, it processes it. Now, if you get the mark-up wrong, it tries to second-guess what you really meant and fixes it up. But then the contract is not fully honoured. If the page doesn’t work properly, it is your fault, but you may not know it (especially if you are grandma) and since different browsers fix up in different ways you are forced to try it in every browser to make sure it works properly everywhere. In other words, interoperability gets forced back to being the user’s responsibility.

Well, the main reason why you have to test your pages in different browsers is CSS, not the mark-up. And if you use a validator to check your HTML, you will get absolutely same HTML parser behaviour in all popular browsers. So you as an author can make sure your webpage doesn’t have any errors, while even the worst malformed old-school tag soup is parsed really similarly (if not exactly the same) by all popular browsers. This is what real backwards-compatibility is.

Now, if HTML had never had a lax parser, but had always been strict, there wouldn’t be an incorrect (syntax-wise) HTML page in the planet, because everyone uses a ’suck it and see’ approach:

1. Write your page
2. Look at it in the browser, if there is a problem, fix it, and look again.
3. Is it ok? Then I’m done

and thus keeps iterating their page until it (looks) right. If that iteration also included getting the syntax right, no one would have complained.

Well, I can speculate on this as well — if HTML didn’t have lax parsers, it wouldn’t be popular at all and something else would’ve been invented. Or it would be used on two pages in the whole WWW that nobody knows about – as XHTML2 is now :) I really think that the low entry cost to publishing a page to web played a very important role in WWW development.

So the designers said for XML “Let us not make that mistake a second time” and if everyone had stuck to the agreement, it would have worked out fine. But in the web world, as soon as one player doesn’t honour the agreement, you get an arms race, and everyone starts being lax again. So the chance was lost.

So I am a moderate supporter of strict parsing … I want the browsers to tell me when my pages are wrong, and to fix up other people’s wrong pages, which I have no control over, so I can still see them.

So he admits a usability issue that draconian error handling in XHTML has and agrees that fixing issues for malformed pages is a good thing. Well, right, nobody will look at a technology that doesn’t provide backwards compatibility. Stick to HTML, Steven — you’ll be able to use validators to check if your code is formed properly and all HTML parsers will fix any errors you, your Grandma, your readers commenting a blog entry (or even your CMS!) will accidentally leave.

There is one other thing on parsing. The world isn’t only browsers. XML parsing is really easy. It is rather trivial to write an XML parser. HTML parsing is less easy because of all the junk HTML out there that you have to deal with, so that if you are going to write a tool to do something with HTML, you have to go to a lot of work to get it right (as I saw from a research project I watched some people struggling with).

What else apart from browsers do we have, Steven? We’ve got Opera (which handles HTML really fine) even on smallest and slowest mobile phones. Every single search engine is able to parse, extract, categorise and rate information from really wildly-crafted HTML pages. If not browsers and search engines, what else?

Look at RSS. Why does it use XML? Only because it was invented, not evolved. There was no backwards compatibility problem and that’s exactly why XML (being a great cross platform structured data storing and transport language) was chosen.

SVG, MathML, SMIL, XForms etc are the results of that distributed design, and if anyone else has a niche that they need a mark-up language for, they are free to do it. It is a truly open process, and there are simple, open, well-defined ways that they can integrate their mark-up in the existing mark-ups.

Absolutely right. All these wonderful extensions are going to be supported in HTML5 HTML serialisation (and look at IE – it’s been supporting data islands, TIME and other stuff for ages!).

So in brief, XHTML is needed because 1) XML pipelines produce it; 2) there really are people taking advantage of the XML architecture.

1. As you say it’s perfectly acceptable to serve XHTML as text/html, it’s parsed as HTML. So if your pipeline generates data that’s acceptable by HTML parsers, why use XHTML?
2. As SVG, MathML, SMIL and XForms are going to be supported in HTML serialisation, why use XHTML?

I’d like to say thank you to Steven and Molly for spending their time, but I still don’t see a single use case for XHTML. If I’m missing anything, I will be happy to fill the gap in my knowledge.