Transitional vs. Strict DOCTYPEs

24 ways, which I’m sure many of you have already heard of, is Drew McLellan’s advent calendar blog that publishes a new web development article every day from the first of December until Christmas Eve. A great idea, and many good articles have already been published there.

Today it’s my turn to be featured. When Drew asked me if I would be interested in writing something for 24 ways (which I obviously was!), my mind went blank for a while. Then I flipped through my notebook of article ideas and found something to write about: Transitional vs. Strict markup.

Here’s the intro from 24 ways:

Roger Johansson returns to first principles and considers the fundamental differences between Transitional and Strict DOCTYPEs, as well as some of the common mistakes made when dealing with each. A timely reminder of the fundamentals can never go amiss.

Impress your friends with your strict adherence

Hope you like it!

Posted on December 13, 2005 in (X)HTML

Comments

  1. I agree with the last line in the article: “I agree with the likes of Ann van Kesteren who argue for not using (X)HTML at all unless you’re prepared to serve the Content-Type as application/xhtml+xml”. There really is no advantage of XHTML over HTML when using text/html.

  2. December 13, 2005 by Martin Smales

    Great article Roger.

    At my work, I found out that my web team at a university already made some headway into separating structure from presentation and we still use the Transitional DOCTYPE for many webpages.

    It does cross my mind a number of times whether or not I should make a page Strict or Transitional and I wasn’t sure, now you made it quite clear to me.

    I think I will be showing your article around that the Strict DOCTYPE is the way to go as we already did some of the separation of structure and presentation of content.

    This will probably enforce good habits in web developers, separation-wise.

  3. December 13, 2005 by Roger Johansson (Author comment)

    klevo: That’s from the first comment, not from the article ;-).

    Martin: Thanks. Strict DOCTYPEs definitely help enforcing good habits, so if this article makes more developers use Strict, that’s great!

  4. December 13, 2005 by Tommy Olsson

    Good write-up, Roger. This needs to be said again and again. I cringe every time I see an XHTML 1.0 Transitional doctype (almost always served as text/html, of course). The sad thing is that those authors probably do believe that they are being modern and future-proof because they ‘use XHTML’.

    The way I see it, a Transitional doctype is something you use during a transitional phase when you’re bringing a hairy old-skool tag-soup document into the 21st century. Before you get rid of all the presentational markup and replace it with CSS.

    Others seem to think that Transitional doctypes are meant to be used in some unspecified transitional period until every browser in use fully supports CSS.

    I don’t subscribe to that notion, mostly because I believe in graceful degradation and am not ashamed to serve unstyled, but semantic, HTML to old dinosaurs. I do realise, of course, that there may be business reasons for catering to obsolete browsers. But I also think that this attitude is holding the Web back.

  5. Great article. I’ve often wondered about the real differences between doctypes and which way to go in my work.

    I’ve always followed the lead of a number of well known sites that are using the XTHML Transitional doctype and it’s always seemed to me (and don’t get me wrong here, I’m not trying to have a dig) that they continue using transitional for a reason.

    This article certainly presents a number of reasons to think otherwise. Well done.

  6. Tommy, it doesn’t matter what authors think they are doing. All that matters is what they actually do. XHTML can either be ‘complete garbage’ pretending to be what it isn’t, or XHTML served as ‘text/html’ for lack of support for anything else across browser-land. Not all authors are stupid, you know.

    The Strict vs. Transitional (vs. garbage that works at times) is important, and should be read and understood by all authors. That will clean up the web ever so slightly, over the years to come.

  7. December 13, 2005 by Tommy Olsson

    I’m not saying that anyone is stupid. Ignorance does not imply stupidity.

    On the other hand, using something for a public web site despite a ‘lack of support … across browser-land’ is something I find it a tad difficult to describe as intelligent behaviour. ;)

  8. So, those who want to create the need for support across browser-land are not behaving intelligently, because they also want it to work today? That’s a new one to me. :-)
    Sounds kind of logical in a strange way. I’ve seen that logic applied by many.

    Well, I’m not implying you are against standards since I am well aware of the facts, but what do we need strict standards for if we don’t push for support?

    After all, HTML4.01 isn’t a standard. It is just a collection of old practices aimed towards FUBAR-browsers, that is written down and called “normative”. We can even get it in Strict.

    XHTML is a ‘standard’ - that can mimic old practices well enough to work even in FUBAR-browsers. There’s a real difference there, and you know it well enough to think twice before advising anyone to stay at FUBAR-level if they can get their heads - and resulting work - around the FUBAR vs. XHTML standard problems.

  9. December 13, 2005 by Tommy Olsson

    Sorry, but I don’t understand what you are saying.

    My point is that using XHTML is an odd thing to do when very few users have browsers that support it. Serving it as text/html to circumvent that negates all potential advantages that XHTML may or may not have over HTML, so there is no gain whatsoever.

    HTML 4.01 is a standard, inasmuch as any W3C recommendation is a standard. It has exactly the same status as XHTML 1.0. It comes in the same three flavours as XHTML, too: Strict, Transitional and Frameset. XHTML 1.0 is merely a reformulation of HTML 4.01 as an application of XML.

    XHTML cannot ‘mimic old practices’. You are relying on parsing bugs in user agents if you serve XHTML as text/html. The fact that it ‘works’ (renders as intended) is due to browser bugs, not to some inherent quality of XHTML.

  10. Ok, maybe my Norwenglish is getting in the way. No big deal. That XHTML1.0 does rely on parsing bugs in old browsers when served as HTML, is a fact. It does work incredibly well too. In fact so well that most authors think they are producing XHTML even when there’s only garbage in their source-code. I think we are in agreement on that sad fact. However, it seems like you want authors to avoid XHTML for that reason, while I want them to fix their flaws, learn their trade and improve their work.

    We know that most authors fall into the habit of relying on bugs, no matter which standard they use. That is a bit harder when XHTML has to work as XHTML in XML compliant browsers in order to live up to the standard it is written in. That is up to each author to make sure of, since browser support is as weak as it is. Even so called XML compliant browsers are still behind.

    So what I want is for authors to produce source-code by a standard and at a quality that will pass in XML compliant browsers at any time. It is easier to ask for widespread XML compliance across browser-land when we have something to serve them.

    There’s of course nothing to gain when serving XHTML as HTML, but there’s nothing to loose either - unless you count flagging of slashes behind the scene as ‘a loss’. I love those red flags - when I am sure that those are marking the only thing that’s “wrong” with my source-code.

  11. Summary: the web author should be aware that XHTML is not HTML so if they use XHTML they should really either; serve it correctly or use practices that wouldn’t break under ‘application/xhtml+xml’ conditions and preferably use a Strict 1.0 DTD over 1.0 Transitional.

  12. December 15, 2005 by Court Kizer

    This entire argument is stupid.

    1) It’s impossible to have a complete business site, with e-commerce, support, and other things a business run and use XHTML stric.

    IE doesn’t render half of it properly… There’s a damn good reason to not use strick, it’s because some of us have to have the sites useable by more than just a few uber-geeks, and developers.

    Gasp. Make me a site in XHTML, strick, that has 2,000 pages, forums, support section, knowledgebase and works properly in IE…

  13. December 15, 2005 by Court Kizer

    Sorry one more follow up. You can’t even make 2 columns site work properly in IE without a hack, let alone make it stickdoc type. If the point is being strick then, you should just say.

    “Sorry XHTML strick sites won’t work with browser that 99% of the world uses. Please change your lifestyle to fit my 1 website.”

  14. December 15, 2005 by Roger Johansson (Author comment)

    It’s impossible to have a complete business site, with e-commerce, support, and other things a business run and use XHTML stric.

    Sorry, but that is nonsense. How is that impossible? Got any specific examples?

  15. IE doesn’t render half of it properly…

    IE6 behaves much better with a Strict Doctype. I really don’t understand any of your comments.

    Cheers for the article Roger!!

  16. Roger, looks like the confusion is complete. Maybe I should have kept my big mouth shut :-)

    IE6 doesn’t differentiate between Transitional and Strict, since it only has a Strict mode. No problem there. Let us all go for Strict.

    IE6 doesn’t have a clue what XHTML is all about, but since most authors only ever serve XHTML as HTML, they don’t seem to have a clue either.

    Now, shall we abandon XHTML altogether, or make the necessary information available to those who care about getting it right - one day?

  17. December 15, 2005 by Roger Johansson (Author comment)

    Georg: :-). I doubt serving XHTML as XHTML to IE is what Court is thinking of though.

    I don’t think we need to abandon XHTML, but we do need to be aware of the consequences of serving it as XML and know how to handle those consequences.

  18. I think both I and Tommy are more concerned about the perils of serving XHTML1.0 only as HTML, and never even test it as XML. More than enough sites that proudly serve XHTML1.1 as HTML already too.

    Oh, well. Let us hope more authors apply Strict procedures to their entire web-work, and not just to their DTD. That might help a little bit.

  19. Roger, nice article over at 24 ways. In reference to checking for obsolete or deprecated HTML, I recently created a tool that lists unacceptable HTML for Strict DOCTYPEs. The SEO Analyzer was originally (and still is) for helping web designers created search engine optimized web design using web standards, but it’s also an excellent checker for semantic structure and proper Strict HTML.

  20. January 1, 2006 by Roger Johansson (Author comment)

    Jon: Thanks. I gave the SEO Analyzer a try, and it seems like a useful tool.

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.