No more Transitional DOCTYPEs, please

For a long time now my answer to people who ask me if they should use HTML or XHTML has been that it doesn’t really matter as long as you use a Strict DOCTYPE and not a Transitional one. If you’re not sure why, my article Transitional vs. Strict Markup for last year’s 24 ways is a good start.

It’s good to see that I am not the only one who thinks that the phasing out of Transitional DOCTYPEs is long overdue (they are called Transitional for a reason, you know). Jack Pickard talks about this in his article It’s Time To Kill Off Transitional DOCTYPES (you can post comments on Jack’s personal website in the identically named It’s time to kill off Transitional DOCTYPEs).

In the article Jack mentions the comment at the top of the HTML 4.01 Transitional Document Type Definition that basically tells you not to use it:

This is the HTML 4.01 Transitional DTD, which includes presentation attributes and elements that W3C expects to phase out as support for style sheets matures. Authors should use the Strict DTD when possible, but may use the Transitional DTD when support for presentation attribute and elements is required.

Well, browser support for style sheets is definitely mature enough that we do not need to use presentational attributes and elements. So unless you have lots of legacy content that contains presentaional markup and cannot easily be converted or cleaned up, go Strict next time you redesign. If you’re building a site from scratch, I can only think of two reasons for choosing a Transitional DOCTYPE. One is if you’re using a lousy CMS that cannot be adjusted to produce Strict markup, the other is if you’re forced to use iframes for incorporating external content.

Posted on September 26, 2006 in (X)HTML, Quicklinks


  1. I have been wondering the same thing lately. There was a short time I used to use transitional, and now I will never use it again. I just don’t understand why someone would use transitional vs. strict. I think there are some nice benefits to using scrict (browser redendering).

    However, I don’t think many even look at the doctype. They simply fire up an editor and let it insert one for them, and, unless they changed the preferences will most likely insert transitional (at least with my experience). So - it does take some knowledge to understand the DTD and how/when to use it.

    Maybe, just as with standards, this is something that takes a little longer to catch on with some…

  2. You know I couldn’t agree more with you on this. Another factor for people who don’t care about this discussion that might be of interest to them, is that to be able to take advantage of all the new CSS support in IE 7, you have to use a strict doctype.

    So, basically, you need to trigger a strict layout mode unless you want to have just one more version of IE 6 (but slightly more secure).

  3. Why “forced” to include content with iframes? You might actually want to, no?

  4. I agree about HTML 4.01, but not about XHTML 1.0 Transitional. Right now, there’s no added benefit to users or developers to use XHTML 1.0 Strict over transitional, either in rendering speed, added features or consistency. A lot of us are forced to use iframes, which you can’t do in 1.0 Strict. Until there’s a compelling benefit to either users or developers, I’m sticking with XHTML 1.0 Transitional.

  5. September 26, 2006 by Roger Johansson (Author comment)

    Nate: Yes, not thinking about the DOCTYPE at all is probably very common.

    Robert: Are you sure about IE 7 and Strict DOCTYPEs? That sounds wonderful, but I looked around a bit and can’t find anything that confirms that. Got a link for us?

    Stuart: I include content with iframes only if there is no other way. I prefer receiving external content as XML since that allows me to use proper markup (unless the XML content includes markup, of course).

    But yeah, if faced with the choice of invalidating and un-semanticafying (that’s gotta be a new word) the main site or using an iframe to keep the nonsensical markup separate, I guess you could say that I would actually want to use an iframe ;-).

  6. I’m sorry, it seems like I jumped the gun with my interpretation… :-(

    I read this quote:

    To preserve application compatibility we will not make any behavioral changes to “quirks mode”…

    in the Details on our CSS changes for IE7 article in the IEBlog but missed one vital set of information. The Doctype switch applies as before, meaning that you will, unfortunately, get away with a transitional doctype as well…

    Argh! So close (at least in my head! :-)

  7. September 26, 2006 by Jonathan Prins

    One reason you may have to use iframes is if you’re incorporating a form into your page, and the post target of that form only allows posts from its own IP address (ie, where the form is actually hosted). This is really only an issue for advertising websites, but may be an issue for others…

  8. Firstly - wow! I made it onto 456 Berea St! I feel like I’m a real accessibility bod now…

    I guess it’s worth pointing out I specifically avoided talking about the frames DOCTYPE for a reason - I personally don’t use frames, and I don’t know enough about when it’s essential to use frames to comment on them.

    That said, it boils down to me to three layers:

    content - (X)HTML

    presentation - CSS

    behaviour - javascript

    In my head, this is the way it should be done. And that’s just my opinion and of course you’re all entitled to disagree!

  9. September 27, 2006 by Sascha

    In my dreams i’m totally into strict doctypes… But in reality, there is this client, who wants this famous _blank hyperlinks. That’s exactly the reason why i choose xhtml 1.0 transitional. (I dont like that “javascript fake _blank hyperlinks approach…”).

  10. September 27, 2006 by Simon Dvorak

    I think IE6’s inability to properly render XHTML strict content is enough reason not to use it at this point for sites that have to cater to the general public.

    Also, using HTML strict allows for bad coding practices like un-closed list items and paragraphs when validating. Sure it would be great if eveyone was an expert and followed good practices without needing the validator to point out thier errors. However, in the university environment that I am in pages are created by people with very limited HTML knowledge. The only way they know they can’t do something is if the validator tells them. So, in my mind, XHTML transitional is really the only way to go if you want good coding practices and cross-browser compatibility when the coders don’t know all the rules.

    Am I missing something?

  11. Legacy code is (un)fortunately the only reason I still use Transitional (HTML 4.01 and XHTML 1.0) DOCTYPEs when developing sites for clients. Frustratingly it’s often just not possible to convince a client to go for a proper redesign — that is, a complete overhaul of the innards of whichever stuffy old CMS they may still be using — instead of just a visual make-over which often only affords me the ability to trade out the old graphics for new, add in CSS and change practically only the front-end of a site.

    In such cases, to at least still keep up my end of the bargain as a web developer attempting to give back to the web by not producing old skool cruft when I know better, I’ll change the DOCTYPE to a Transitional one so all the (often proprietary) elements and attributes deprecated or no longer supported in Strict DOCTYPEs will at least not make the W3C validator splutter and die from all the errors and warnings. It’ll just hiccup indignantly.

    Sometimes I can cheat and use unobtrusive JavaScript to strip the worst of it away (target="new"? Huh?) but of course even the most unobtrusive script will still be useless to a user who has turned JavaScript off in his/her browser and it’s in any case the very last “fix” I reach for if I can’t work anything else out. I guess I still need to work on my “Why web standards are a Good Thing: A primer for the lay person” speech. >_<

  12. Simon Dvorak: I think that’s a rather pessimistic view. Validation isn’t the be-all and end-all of web development, agreed, there’s a whole lot more to it especially when impatient clients are thrown into the mix. However, it’s not a “nice to have” either. I’m passionate about my chosen profession and before my fingers close that last open document on a project I’ve been working on, I have to be satisfied. What that means is that the final validator of a piece of work I’ve done will always be me and I have no other mode than strict. My pay-off for the work I do at the end of the day isn’t just monetary, it’s the pride I can allow myself to feel when I know I’ve done my best. Good coding practices for me comes from all over — sites like this one, the W3C validator and very pleasantly increasingly more often, my own inspiration. You can only learn how to do things the right way when you’ve learnt about all the incorrect ways that it has been done before and this is how I’ve approached my never-ending journey of learning how to design sites the best that I can.

  13. using HTML strict allows for bad coding practices like un-closed list items and paragraphs when validating.

    As I understand it, the point of specifying a doctype is to declare what set of rules you’re playing by. No doctype is particularly “more correct” than any other. They define correctness within the context of what they are applied to, much the same way as it’s not really possible or appropriate to compare religions. Transitionals aren’t so much wrong as not intended to be an end point. As Roger said: just look at the name.

    If unclosed tags or whatever else are valid under the strict HTML doctype, then it’s not a bad practice. You may not like it, but that doesn’t make it wrong. In fact, the doctype specifically allows it. If you want people to change their choice in doctype, that’s a separate discussion. But maybe I’m missing more than you are.

  14. As you mention, CMS that don’t produce Strict code are a major problem. I’ve been using Transitional XHTML on this basis for the last 8 or 9 sites I’ve been working on (restricted to CMS by business reasons). The sooner they provide good templating (Smarty is quite capable of handling XHTML Strict, and I’d assume most other mature templating systems can do it as well), the sooner we can get rid of the Transitional doctypes.

  15. Interesting article, I’ve been following this subject with a view to making a switch from transitional to strict. However, the recent post on the Surfin’ Safari Blog titled “Understanding HTML, XML and XHTML” has some additional food for thought, the following quoted paragraph sums it up:

    So what really determines if a document is HTML or XHTML? The one and only thing that controls whether a document is HTML or XHTML is the MIME type. If the document is served with a text/html MIME type, it is treated as HTML. If it is served as application/xhtml+xml or text/xml, it gets treated as XHTML. In particular, none of the following things will cause your document to be treated as XHTML:

    • Using an XHTML doctype declaration
    • Putting an XML declaration at the top
    • Using XHTML-specific syntax like self-closing tags
    • Validating it as XHTML

    In fact, the vast majority of supposedly XHTML documents on the internet are served as text/html. Which means they are not XHTML at all, but actually invalid HTML that’s getting by on the error handling of HTML parsers. All those “Valid XHTML 1.0!” links on the web are really saying “Invalid HTML 4.01!”.

    It perhaps adds a little more to think about.


  16. I must agree with the stance that Transitional doctype have to go the way of the dinosaur. Alas most CMS’s can’t generate the needed code and many sites use advertising systems that require iFrames. But otherwise all and all I’m in favour of Strict Doctypes.

  17. Ah, so all we have to do is kill off lousy CMS’s? :)

  18. Another factor is that a lot of people use tools such as Visual Studio, which doesn’t exactly promote the usage of strict doctypes. Sure, there are several ways to work around this (custom controls, xhtmlConformance, App_Browsers folder and so on), but that will only mean something to the one percent of ASP.NET developers who actually care about web standards. The rest simply don’t care if there is a doctype at all.

  19. On reading this I checked the W3C, to see what I may have to change to apply a strict DOCTYPE. Their guideline page is transitional. If they can’t be bothered, I think you’re on a hiding to nothing on this one :)

  20. September 27, 2006 by zcorpan

    Robert, no, you don’t need a Strict doctype to get the fancy features in IE7. You need a doctype that triggers standards mode — or “strict mode”, as MS call it — and the HTML 4.01 Transitional doctype with system id aswell as the XHTML 1.0 Transitional doctype triggers standards mode in IE7 (so long as there are no comments before it).

    However, some browsers have three rendering/parsing modes; in addition to quirks and standards they have “almost standards mode”, which reserves some quirks such as handling of vertical sizing of table cells and how they parse HTML comments.

    To me the choise of doctype for text/html documents are solely for picking a rendering/parsing mode in browsers. You can choose what you want to validate against when validating (e.g. using doctype override in the W3C Validator).

  21. September 27, 2006 by Christian

    If you know you can’t control the output to 100% … what doctype (strict/transitional) should be used? If the code won’t validate in either case, does it matter?

    I go for HTML 4.01 Strict, but are there any “dangers” in doing so, instead of using a transitional?

  22. […]The elitists are doing the rounds again by advocating that the goal posts shift on what is required to produce a web site. The message this time is[…]

  23. September 27, 2006 by Roger Johansson (Author comment)

    Robert: Good to have that sorted out. It would have been awfully nice if Microsoft had changed IE 7 to only use strict mode with a strict DOCTYPE though.

    JackP: Lol :-D. It’s a good article! About frames DOCTYPEs - those are for frameset and frame elements, not iframes (inline frames). Slightly confusing, but that’s the way it is.

    Sascha: I personally prefer the opposite.

    Simon: I’m not sure what you mean by “IE6’s inability to properly render XHTML strict content”, unless you mean XHTML served as application/xhtml+xml. I haven’t noticed any problems with IE and XHTML 1.0 Strict (served as text/html for obvious reasons).

    Using HTML Strict does allow less strict coding practices, so yeah I can see your point about people needing the validator. However it’s important to note that there is nothing in HTML that requires you not to close your li and p elements.

    Rick: Yeah, that article is good and provides more food for thought, but that whole HTML vs. XHTML discussion is separate from the discussion on Transitional vs. Strict.

    Krijn: Yep. No small task though ;-).

    Reine: Absolutely. IDEs tend to produce and encourage sloppy markup.

    Martin: When visiting the W3C site, you have to keep the phrase “do as I say, not as I do” in mind ;-).

    Christian: The only danger I can see is reducing the chance of the site being valid.

    As far as I know, rendering differences with invalid HTML or CSS only occur between different rendering modes (standards or quirks). You can trigger Standards mode (but not Full Standards mode in Gecko browsers) by using a Transitional DOCTYPE with a system identifier.

  24. can you outline a good cms that produces XHTML stict and that will not allow for users of the CMS to produce invalid code.

    I can think of a few blogging systems that do this but that are limited compared to other CMS.

    Also you need to educate the others (non techies) about how to add things like alt tags. If you cannot force them to do this in a CMS then it is really difficult to see a quick uptake of XHTML strict wholescale as there are too many issues with the IE quirks mode. As I understand it, any errors at all in code will make for quirks mode (back to IE4 render engine). So every < br> is going to trigger this, that could be a lot of cleaning up on a lot of sites, also every link will need a title … .

    I understand your argument for pages produced by web designers, it is just that majority of the web is now going to be produced by people with less knowledge and transitional fits the gap until web standards is across the board on all CMS systems.

  25. sorry read your other article and it appears I am wrong about those tags, however surely when creating good xhtml these practices are just as important

    probably the most important thing is the character entities and their support in wysiwyg editors that CMS use, if they dont convert to html equivalents this is sure to make code invalid, no?

  26. October 25, 2006 by Romas K

    Talking about CMS and their invalid XHTML output: you can always change predefined XHTML output strings in CMS configs…But I guess not all CMS systems introduce a way to alter XHTML tags for output.

  27. would anybody kno wat has to be done to get the iframe working in IE7 which should still use strict doc type??

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.