This is a well-discussed and very important topic. Personally, presently I write XHTML for my web interface code, but lately I’ve started to stagger in my standpoint. For normal general web page design, what’s the gain? If you don’t extend the code with namespaces, use MathML, have your own DTDs and so on, why would you want to use XHTML?
Many people answer that question with: “It makes me write leaner code, code that has to validate and be more semantic correct”. Martin wrote a post recently why he uses XHTML (unfortunately, it’s in Swedish).
But I don’t agree with the argument that it has to be XHTML to achieve that particular goal. I think it’s more of a developer standpoint than using XHTML. If you’re really dedicated to what you do, you use the correct tags for the correct purposes (H1 for headings etc), you write as lean and minimal code as possible and you close all optional tags like LI, P and so on.
Another reason people use it is that they might think it makes them better programmers, that they code ‘the real deal’. It might also be as a selling point, for the project manager or his/her like, to tell the customer that: “Yes, we know what we do, we code XHTML”.
But, unfortunately, very few do it all the way. As mentioned in Anne‘s Quick quide to XHTML about Evan Goer’s test, 89% of the web sites tested didn’t validate and 99% used the incorrect MIME type!
Which leads to the MIME type issue. In a very talked-about piece, Ian Hickson writes that if you use XHTML it should be delivered as application/xhtml+xml (which, surprise, Internet Explorer doesn’t support) to the web browser, otherwise it will be perceived as ‘tag soup’ (however, not everyone agrees that it should be called ‘tag soup’). But what has happened is that people have gone to such length that they use something called content negotiation, which basically boils down to serving XHTML as application/xhtml+xml to those web browsers who support it, and HTML 4 as text/html to those who don’t.
When you deliver XHTML as application/xhtml+xml to a browser that supports it, it won’t even render the page if it’s incorrect, but instead throw an error. Generally, I think this is a good thing that forces the developer to write correct code. Alas, speaking from my point of view, working in projects where Content Management Systems don’t deliver correct XHTML, where the .NET Framework doesn’t deliver correct XHTML etc, serving it as application/xhtml+xml is impossible for me.
Yes, Content Management System manufacturers are getting more aware of this, ASP.NET 2.0 is supposed to deliver XHTML the way it should be delivered, but it’s still a long way ahead in the future.
So what are my (and many other developers’) options? To deliver XHTML that doesn’t validate (although the errors might be minor/make no difference to how it will be rendered) as text/html, or should we deliver plain old HTML?
One point is also that this will not affect the end users, as long as you write valid code in its context, be it XHTML or HTML.
An interesting sidenote to this is that MSN Search serves valid XHTML 1.0 Strict which validates, while Google serves a non-Doctype page which generates 242 errors…
Conclusively, to go back to my initial question: why use XHTML if I only use it for standard HTML? Why go through the hassle if I don’t use any of the XHTML-specific features?
Anne brought up an interesting thing from Mozilla’s Web Author FAQ about how to serve HTML (and the thing that Mozilla, nor any other browser, loads XHTML incrementally, as opposed to HTML), and he comes to the conclusion that one should switch to HTML.
And these are two very talented persons that just don’t believe in XHTML anymore, and that saddens me and makes me think:
Are they right? Should I go back to writing HTML?
PS. Let me know what you think! Is XHTML or HTML the way to go? Write a comment and I’ll send you an invitation to use Google’s Gmail service (2 GB inbox(!), POP3 access etc). DS.