HTML or XHTML?
In Spanish/En Español
På Svenska/In Swedish
It seems like the eternal question amongst web developers: HTML or XHTML? Wherever I look there seems to be posts in forums raising the question, web developers asking me or other people write blog posts about what they believe is the right way to go. I’m not writing this post to tell you what the ultimate choice is, but rather to inform you about the consequences of what you choose. So, let’s take it from the top:
Strict or Transitional?
Definitely strict. Transitional doctypes are exactly what the name implies: a doctype for a phase of transition, not meant to be used permanently. If you write HTML and choose Transitional, you will get the Quirks Mode rendering, which results in web browsers just trying to mimic old and incorrect behavior; this means that rendering will be very different from web browser to web browser. If you choose XHTML Transitional, you will get the strict (or rather, strictest) mode available in IE (Note: from version 6) but you will trigger the Almost Standards Mode in Mozilla-based web browsers.
However, if you use a strict doctype, you will get full standards correct rendering and the most consistent and forward compatible interpretation of your pages.
What is XHTML?
A XHTML document is a document that has to be well-formed according to the rules of XML. Every tag has be closed and correctly nested, and for tags like img, input, link etc, a quick close slash should be added at the end of the tag, like this: <input type="text" />. If you’re writing code that should be accessible for people with Netscape 4 and some other web browsers, then make sure to have a space before the slash (Note: not to make it look good in Netscape 4, but to make it work at all).
You’re supposed to be able to save a page written in XHTML and use it as XML right away.
Why XHTML?
It totally depends on your needs. Some people believe it to be very easy and consistent to code in its XML fashion, where everything has to be well-formed and every element has to be closed. Some people choose it to extend its functionality with namespaces, to use it in conjunction with MathML and so on. Other people might work with XHTML, not out of their own choice, but because the products they/their company use deliver XHTML.
I’ve heard something about application/xhtml+XML?
Yes, it’s all about what MIME type goes with your code. For HTML, the media type is text/html. According to W3C, the organization behind many recommendations such as HTML, XHTML etc (albeit mostly known as web standards), state in their XHTML Media Types document:
‘application/xhtml+XML’ SHOULD be used for serving XHTML documents to XHTML user agents. Authors who wish to support both XHTML and HTML user agents MAY utilize content negotiation by serving HTML documents as ‘text/html’ and XHTML documents as ‘application/xhtml+XML’. Also note that it is not necessary for XHTML documents served as ‘application/xhtml+XML’ to follow the HTML Compatibility Guidelines.
What this translates to is that web browsers who can handle application/xhtml+XML should get it served that way. However, IE doesn’t support that media type, thus requiring you send the code as text/html to it, basically resulting in you having to deliver the pages with different media types to different web browsers, using something called content negotiation. By now, you probably think it all sounds like too much of a hassle, and choose to go with text/html all over. I mean, after all, the Appendix C. HTML Compatibility Guidelines presents the validity of serving XHTML as text/html.
However, then you read this:
XHTML documents served as ‘text/html’ will not be processed as XML [XML10], e.g. well-formedness errors may not be detected by user agents. Also be aware that HTML rules will be applied for DOM and style sheets…
Which means that web browsers will not render your pages as XHTML, but rather as HTML and fall back on error handling and trying to guess how it was meant to be. Then you’re most likely back at square one, because you probably don’t want it this way.
Also, something else that is utterly important to know is that certain scripting will not work when sent as application/xhtml+XML. For instance, if you use document.write or have ads on your page through an ad content provider using it (such as Google AdSense), it will stop working. If you implement an AJAX application using the innerHTML property on an element, that won’t work either.
What’s Robert’s opinion?
My personal opinion is that the most important thing is that you choose a strict doctype, be it HTML or XHTML. If you want to use XHTML and serve it as text/html, make sure that you don’t intentionally have code that would break when served as application/xhtml+XML. Do not use scripting like the one above mentioned in an XHTML page, and go the extra mile to make sure it is indeed well-formed. Be also very aware that a page that isn’t well-formed sent as application/xhtml+XML will not render at all, but will instead only display an error message to the end user.
Anne used me as a bat for HTML, but I’d rather be seen as a spokesman for making a thought-through decision, no matter which one it is. I sometimes work with HTML in may daily job and sometimes XHTML, depending on a lot of factors.
So, choose what you think suits your needs best, and choose wisely. And make sure it’s a deliberate decision.
Related reading
- The Road to XHTML 2.0: MIME Types (a.k.a. XHTML’s Dirty Little Secret) by Mark Pilgrim
- How browsers work by Anne van Kesteren
- Activating the Right Layout Mode Using the Doctype Declaration by Henri Sivonen
- XHTML and error handling by Robert Nyman
