I’ve never really understood why people use transitional doctypes. Perhaps this comes from my time working in libraries: 7 years being beaten over the head with MARC format and various other library standards gave me a sense for correct coding before I ever sat down and decided to develop websites.
Data formatting is, believe it or not, quite important. The power of XML (eXtensible Markup Language) is wrapped up in formatting – if you’ve left off a closing tag or incorrectly nested XML, you’ve lost significant parts of the overall meaning of the document. Even though HTML (HyperText Markup Language) isn’t XML, why should it be treated with any less rigidity? The debate between HTML and XHTML (eXtensible HyperText Markup Language - HTML reformulated as XML) has been going on for a long time – and it’s commonly opined that the most important choice is actually between strict and transitional doctypes.
Recently, this topic has experienced a bit of a resurgence in discussion:
My opinion falls squarely in the XHTML 1.0 Strict camp. I don’t feel there’s any value in using XHTML 1.1; but I DO feel there’s a value inherent in the rigidity required by XHTML, thus my preference for that over HTML. What are the issues surrounding XHTML 1.0 Strict?
XHTML and HTML MIME Types
A common argument raised by HTML advocates is the fact that most XHTML documents are delivered to the browser using the MIME type text/html. In many browsers, this means that the document is treated as HTML, regardless of the declared document type. In order to actually deliver XHTML, the MIME type application/xhtml+xml or text/xml is required. Without this MIME type, the advantages of XHTML are irrelevant. (Of course, you can’t serve application/xhtml+xml to Internet Explorer, but that’s a separate issue.)
Or are they?
Actually, I consider the MIME type issue to be more or less irrelevant. My own reasons for using XHTML 1.0 Strict are for consistency. I really dislike the fact that HTML doesn’t require all tags to be closed in order to be valid – and, in fact, requires that certain tags (<link> for example) must NOT be closed. Yes, this is petty: but to me, it’s sufficient reason to not use HTML.
What are the benefits to Transitional Doctypes?
Well. They allow support for legacy code. All right – that’s acceptable. Older projects can use transitional doctypes. What else? Ah…they allow the target attribute for anchors, a commonly desired feature for links designed to open in new windows. Simple: don’t do it. I can accept that there are certain special case uses where forcing a new window is necessary, but I see no reason not to use Javascript to force the new window, as long as the link is left usable when Javascript is disabled.
I’ve heard a variety of other ideas: transitional doctypes for browser compatibility (something which I’ve always observed, personally, to be a problem), transitional XHTML doctypes because transitional allows you to deliver XHTML as text/html (a fallacy, as far as I can tell). None of these other ideas seem to hold water, however.
There is one, final reason to use alternate doctypes: and it’s one which is very annoying to me. Many 3rd party tools are run through <iframe>s – most types of Amazon affiliate links and many types of embedded content. If you want to incorporate this kind of tool, you’re pretty much stuck either failing to validate or using something other than the strict doctype.
Frustrating…and I don’t have any kind of an answer for it.
Conclusion
When you examine the issues this is a tricky question. There are lots of reasons to use both doctypes, and there are perfectly good reasons for using HTML and XHTML. Personally, I’ll use transitional doctypes exactly the way they’re intended: only when absolutely necessary. Otherwise, it’s strict all the way. I’ll always choose XHTML if I have any choice, because I prefer it: and someday, when browsers can actually consistently handle the XHTML as XML, I’ll celebrate. Until then, I’m just not going to worry about MIME types.
Joe Dolson
That’s a fair argument, Stevie – so, for you, HTML (HyperText Markup Language) is a more logical choice – it matches your internal expectations for code behavior.
I’m not saying that XHTML (eXtensible HyperText Markup Language - HTML reformulated as XML (eXtensible Markup Language)) is “the right way to go”. I’m more trying to emphasize that there are a multitude of reasons for picking one or the other. For myself, my own sense of internal consistency suggests XHTML.
Personally, at least when it comes to the <img> tag, I think that the tag itself is specified poorly. The img tag should be a container for an image: with an opening sequence and a closing sequence appropriately. Instead, it was created so the src is referenced as an attribute of the tag. That’s fair – it’s also a possibility with the <script> tag.
I consider the <br> tag to be anomalous: it doesn’t really fit with my conception of semantic code because it contains no meaning within the document at all. I do make use of it, but prefer to minimize that use when I can.
Thanks for your comments!
Stevie D
You say you don’t like HTML (HyperText Markup Language) because it allows stand-alone tags that don’t need closing, like [img] and [br] – but that’s one of the things I do like about it!
Yes, a paragraph, or a hyperlink or table cell or list item, has clearly defined content and so can sensibly be wrapped in “beginning” and “end” tags. That much makes sense.
But what about line breaks or images? These don’t have any content (in the main flow of the document) – you can’t put anything between the beginning and end tags! So why not be happy that these are spot tags that mark an instance rather than a section, and need no closing?
Joe Dolson
Thanks, Mike.
Been there…that definitely influences my decision a fair amount, as well. It’s simply much easier to do all my sites in ONE format – keeps the mind stiff and inflexible. š
Mike Cherim
Good article, Joe. I like the points you make up and reside on the matter where you do. I like your mention of the anchor target attribute. People use an XHTML (eXtensible HyperText Markup Language - HTML reformulated as XML (eXtensible Markup Language)) Transitional DTD (Document Type Definition) oftentimes to allow its continued use. But guess what, folks, there’s a reason that is being pushed to the wayside. It’s no longer cool to spawn new windows, mixing behavior into the mark-up. It shouldn’t be used on a publicly accessible website (an intranet or browser-based CMS (Content Management System) might be good exceptions).
My main reason to use the XHTML Strict DTD over HTML (HyperText Markup Language) strict — which I do exclusively, even though I serve my documents as text/html — is that it puts me that much closer to the day when I change my site’s MIME types to a supported version of XML. Moreover, I have tried using both before, but I found switching between the two made me think too much. Post-validation and I’d have to go back and fix XHTML boo-boos in HTML documents and vice-versa.
Emma
Thanks for the extended explanation! I’ve always wanted that question answered, and now it has been.
Joe Dolson
Well, first there’s the fact that a browser which receives your XHTML (eXtensible HyperText Markup Language - HTML reformulated as XML (eXtensible Markup Language)) sent as text/html will read it as HTML (HyperText Markup Language) – so, from a rendering perspective, it’s malformed HTML rather than well-formed XHTML.
Some would argue that this means all supposedly valid XHTML sites are actually invalid, because they are processed as broken HTML: I don’t agree, because I believe that the validity of code is inherent to the structure of the code, not to the rendering capabilities of the user agent. The fact that a user agent can’t accept my code doesn’t necessarily make my code invalid.
Also, since the browser reads your source as HTML, you can’t take advantage of many of the XHTML modular namespaces: MathML, XHTML-MP, or custom made namespaces. Since part of the whole point of using XHTML is the fact that it’s parsable in XML, NOT being able to use this XML spaces is a bit inconvenient.
The fact is, this downsides to serving as text/html are pretty esoteric – if you’ve written valid XHTML and served it as text/html AND tested your site thoroughly in a wide range of browsers, you’re just fine. If you want to add any extra functionality by adding additional XHTML modules, you’ll have to switch.
And, if you decide to switch to serving application/xhtml+xml at any point – you’ll have to check over your site again, very thoroughly, in all browsers, because the rendering is likely to change.
Well…that was practically a whole new post…
Emma
What advantages do you lose by serving it as text/html instead of application/xhtml+xml?