Summary
One of the things that constantly amazes me, is the number of brand new websites built using a Transitional DOCTYPE. Has the Transitional DOCTYPE had its day?
Author: Gez Lemon
Contents
- Document Type Definitions
- Brief History of Markup Specifications
- Using a Transitional DOCTYPE on Today's Web
Document Type Definitions
Each element in a markup language has a relationship with other elements within that language. The relationship between the elements defines the structure of the data. A Document Type Definition (DTD) provides a formal definition of the elements and associated attributes for the document structure. A DOCTYPE is a statement that should be included at the top of your documents identifying which DTD you are using. The W3C defines several DTDs that may be used for publishing documents on the Web. The two most common factors when deciding on a DOCTYPE are:
- XHTML or HTML
- Strict or Transitional
HTML 4.01 is the last version of HTML defined by the W3C. There will be no more versions of HTML, as it has been superseded by XHTML. HTML is still a valid standard, and due to the number of HTML documents out there, will be around for many years to come. Because of the poor support for XHTML in the current version of Internet Explorer, undeniably the most popular browser around today, HTML 4.01 is still a good choice for content developers. XHTML has the advantage that the markup must be well formed, and can be loaded into an XML parser to manipulate the document. Is there a reason to use XHTML if you're not using XML tools? The transition from HTML Strict to XHTML Strict is merely a case of making sure the document is well-formed, and changing the DOCTYPE. In short, there's no advantage to using XHTML on today's web.
Brief History of Markup Specifications
HTML 3.2 was an official W3C recommendation in January 1997. The first official W3C recommendation for HTML 4 was published in December 1997, and went through several revisions until the final version (HTML 4.01) was published in December 1999. The first working draft for the reformulation of HTML in XML was released in December 1998. XHTML became a W3C recommendation in January 2000, and was revised in August 2002. At the time, there was a lot of legacy markup around, and they needed a DOCTYPE that would allow developers to move to newer standards without breaking what they already had. The solution was to provide a Transitional DOCTYPE. An HTML Transitional DOCTYPE allows developers to make a transition from HTML 3.2 to HTML 4.01 with minimal impact on what they already have. Developers can then amend the code, until they're able to work with the Strict DOCTYPE, which deprecated a lot of the presentational elements and attributes, aiming to separate presentation from content. An XHTML Transitional DOCTYPE allows developers to make a transition from HTML 3.2 to XHTML 1.0, with the same benefits as those making the transition to HTML 4.01.
Using a Transitional DOCTYPE on Today's Web
There seems to be a common misconception that the XHTML Transitional DOCTYPE is for developers to make a transition from HTML 4.01 to XHTML 1.0. It's utter nonsense, as the HTML 4.01 DTD and the XHTML 1.0 DTD are very similar in the rules they apply. The only difference is the well-formed issues that any XML application must adhere to, whether it's Transitional or Strict. So which is the better DOCTYPE? HTML 4.01 Strict, or XHTML 1.0 Transitional? Without a shadow of doubt, the HTML 4.01 Strict DOCTYPE is a far better than XHTML Transitional, as it deprecates presentation elements such as font, and presentation attributes such as align. XHTML Transitional merely means you've ensured it's well formed.
The HTML 4.01 Transitional DTD states:
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.
With this in mind, I'm amazed at the number of brand new sites, or even well maintained sites with a Transitional DOCTYPE. Why on earth, in 2004, would developers be using parts of a specification that were updated well over 6 years ago? Whenever I ask developers this question, the stock response is, "XHTML Transitional is a valid standard". And of course, they're correct; it is. And so is HTML 3.2, so why haven't they chosen that DOCTYPE, and enjoy the thoroughly legal mixture of presentation and content elements/attributes? Another common response is that XHTML Strict should be delivered with the correct MIME type. But so should XHTML Transitional. If you're going to ignore the advice completely, ignore it using the Strict DOCTYPE. The only XHTML version that the W3C recommend *should not* be served as text/html is XHTML 1.1. Some developers are prepared to ignore that too, as *should not* is not as serious as *must not*.
If you use an XHTML Transitional DOCTYPE, ask yourself why. If you're honest, the answer will either be because you can't live without the presentation elements that a Transitional DOCTYPE affords, or because you want to launch new windows. Launching new windows is a whole new subject, but I'll briefly mention that the user interface isn't part of your document, and should be left to your visitors to decide where they want links opened. It's time to move forwards.
Category: Markup.
[choosing-doctype.php#comment1]
is serving xhtml1.1 as text/html to browsers that dont support application/xml + xhtml bad even if it is served with the proper mime type to browsers which support it?
good article btw gez
Posted by nutter9k on
[choosing-doctype.php#comment2]
Theoretically, yes. There's the Appendix C compatability guidelines for XHTML 1.0 http://www.w3.org/TR/2000/REC-xhtml1-20000126/#guidelines but XHTML 1.1 should be marked up properly. In reality, it just means that the document will be treated as tag soup by those browsers, which is all they can cope with anyway.
Thanks, Nutter
Posted by Gez on
[choosing-doctype.php#comment3]
The Appendix C compatability guidelines apply only to XHTML 1.0, not to 1.1.
XHTML 1.0 *may* be served as text/html, XHTML 1.1 *should not* be served as text/html.
Should not means [http://rfc.net/rfc2119.html]:
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
Given the advantages of XHTML 1.1 over XHTML 1.0 (you get Ruby), it is pointless for most people to use it. So stick to 1.0 which you 'may' serve as text/html. (But if you do go with 1.1, then use the 1.0 Appendix C - its part of the 'full implications' thing).
Posted by David Dorward on
[choosing-doctype.php#comment4]
Gez,
I didn't get your article at all - specifically I couldn't see what was in it for either the user or the developer.
As a user, I find my browsers render all sorts of pages well enough.
As a developer, I think there are far too many DOCTYPES, especially since the introduction of DOCTYPE switches to set browsers into strict or quirks mode (IE is the main offender but I'm sure there are others). As far as I can see, using a strict DOCTYPE makes it more difficult to produce pages that render much the same in a wide range of browsers.
Using a strict DOCTYPE also brings some functional restrictions, like the lack of a TARGET attribute in strict XHTML. I hate advertising pop-ups (which spawn themselves if you have Javascript on), but there are situations where opening a link (clicked by the user) in a new window is good for the user, e.g. a Help page or glossary.
Posted by Philip Chalmers on
[choosing-doctype.php#comment5]
Using a strict doctype and adhering to standards results in pages being rendered more consistantly on modern user agents. The benefits for developers separating presentation from content are obvious. If the lack of a target attribute concerns you, then a strict doctype isn't for you.
Posted by Pia on
[choosing-doctype.php#comment6]
Firstly I'd like to seconds Pia's comment.
Obviously everyone wants to develop a website that will render as expected across as many browsers as possible whilst still providing the same level of functionality. In my opinion, transitional dtd's should only be used as a short-term solution until the website in question can be coded to a strict dtd.
The web will never 'move forward' as long as transitional dtd'd are being implemented as permanent solutions. Using a transitional dtd wont encourage users to update their browsers (which isnt a hard task given the numerous means of distribution these days).
Please correct me if Im wrong, but doesnt IE only enter "quirks" mode when: (a) no doctype is specified, or (b) if the full URI to the dtd is ommitted from the doctype declaration?
I dont think the lack of the target attribute in XHTML Strict is a bad thing, definitely not a reason to stick with the transition dtd. As developers, we must give users some credit by assuming they know how to open a link in a new window should *they* wish to (i wont go into the accessibility implementations).
However, if new windows are required, doesnt the modularisation of XHTML 1.1 provide the ability to open links in new windows whilst still adhering to the XHTML standard?
I dont expect everyone to agree with me (that would be boring!), but I think Gez's article makes a very valid point.
Posted by Si on
[choosing-doctype.php#comment7]
I've never come across that problem. Do you have an example?
Browsers have to work particularly hard to ensure they render documents correctly. When serving XHTML without the correct MIME type, the browser relies on its error handling capabilities. See Ian Hickson's excellent article for more information: http://hixie.ch/advocacy/xhtml
Internet Explorer also uses quirks mode if any content whatsoever is placed before the DOCTYPE. That means that if an XML declaration, such as <?xml version="1.0" encoding="utf"?> is used, then Internet Explorer switches to quirks mode.
Thank you
I don't expect everyone to agree with me either - but developers who go to the lengths of specifying a DOCTYPE do so in order to instruct the browser which version of the standards they will be using. As has already been mentioned, this may instruct some user agents to switch to a certain mode (standards or quirk). A DOCTYPE is also required for validation services, who without some identifier as to which specification you intend to adhere to, wouldn't know where to begin with the validation. If a DOCTYPE isn't important, then this post can be dismissed. Verifying that a document adheres to old standards seems a bit pointless to me.
Posted by Gez on
[choosing-doctype.php#comment8]
I use Strict or Transitional XHTML 1.0 DOCTYPE, depending on whether or not the page needs an iframe element. The iframe is not in Strict.
Alas, when presenting certain kinds of media, the object tag does not work properly in all browsers, not even the Mozilla versions. Change of media content may not be scriptable, or it may require different script per-browser, per-media player. Or, if the media has visual content, it may fail to un-draw before new media is presented. DOM2 node methods equally fail, depending on the browser and media player.
When I need to script change in a media player, the only satisfactory solution (cross-browser, cross platform with contemporary full visual browsers) is to put the media player in its own web page, in an iframe of the parent. The iframe contents are changed the same way in all instances. (I have also found a way to cirumvent the back-button problem in some browsers).
I do not care whether some refrigerator or toaster, connected to the Internet so it can download culinary instructions, is able to interpret my audio-visual web pages! Nor do I anticipate that cell phone users will be greatly disappointed.
Posted by Robert A. on
[choosing-doctype.php#comment9]
Good for you. This site is really aimed at those who do care, but thank you for stopping by and sharing your thoughts.
Posted by Gez on
[choosing-doctype.php#comment10]
Where can I go to find clear, understandable English-language information about how to write correctly for xhtml 1.0 transitional? I understand what 'well-formed' means, at least I think I do. But there are things being flagged by the validator that I don't understand, and I am stuck working w/ this spec because some parts of my site use XML tools, and I know the pages aren't validating, and want to fix them. I can't control all the content rendered into the site, and thus can't live w/o the deprecated presentational entities.
In articles like this I could live with less snotty attitude and more straight ahead information.
Thank you.
Posted by Lori on
[choosing-doctype.php#comment11]
I don't know of any website or book that offers advice on writing XHTML transitional documents, although there must be some about. Probably the best resource on the web for all valid elements and attributes, and how they should be used is: http://www.htmldog.com/ You should be able to find references for what you're looking for there, or at least an equivalent.
I strongly suspect it's complaining about attributes and/or elements that aren't part of any specification. XHTML Transitional at least expects the document to use attributes defined in HTML 3.2. Unfortunately, a lot of developers use attributes and elements that are browser specific, and that may well be the problem you've encountered.
I'd like less snotty commentors; looks like we're both going to be disappointed.
Posted by Gez on
[choosing-doctype.php#comment12]
After much poking around, it appears that the validator was flagging 'onMouseOver', and was mollified by changing it to 'onmouseover'. So, case matters for attribute names, and even seemingly valid attributes will be flagged as bad if they are anything but lower case.
This is hugely useful information, and has permitted me to correct many things in advance. And this is what I mean by 'English language' information.
Yes, life is full of disappointments.
I'm not so completely clueless that I'm using HTML 3.2 stuff, I'm just working through the content of a site that I've largely inherited, and it is full of random stuff written by WYSIWYG editors and other well-meaning but uninformed contributors. So, it's a slog.
Posted by Lori on
[choosing-doctype.php#comment13]
Case also matters for elements. XML is a case-sensitive markup language, and XHTML is just HTML reforumated as an XML application.
It is useful information. It's also absolutely fundamental information that anyone working with XHTML should know. It's the very first thing that any good website teaching XHTML, or good book on XHTML would explain right at the start.
With respect, I'm not sure why you think an article talking about choosing an appropriate DOCTYPE would provide you with that information. This article is aimed at people who already know XHTML, but choose a Transitional DOCTYPE for its presentational capabilities.
You have my full sympathy there; it's a thankless task. Good luck with it.
Posted by Gez on
[choosing-doctype.php#comment14]
Well, to me, choosing a doctype depends on what I 'gain' and 'lose' in the case of various choices. With a strict doctype, you gain more precise rendering vis a vis the standards (yes?) but you lose access to a number of deprecated but still very common tags and attributes. So, knowing how much fussy hand cleanup I have to do on hundreds of already existing pages, and what the details of that cleanup will be, is totally related to the question of doctype.
I did already know about capitalization in tags & attributes, but had seen the javascript event handlers typed as 'onLoad', and 'onMouseOver' in files that did validate as HTML 4.01 transitional, so the case error in those attribute names weren't flagged.
Also, why the hell doesn't the w3c validator just say that the attribute is miscapitalized instead of 'invalid'? If the geniuses at microsoft can flag case errors and not treat them as mis-spellings, why can't the W3C?
Posted by Lori on
[choosing-doctype.php#comment15]
No. The markup is merely used to provide the structure for the document. Using a DOCTYPE correctly may cause a browser to go into standards mode as opposed to quirks mode, but that's incidental; rendering is usually consistent in either quirks or standards mode, but not with each other. User agents will render the elements according to the base style sheet used by the browser. For example, an h1 element will typically be rendered larger than any other heading element. Choosing semantically correct elements means that people using assistive devices can navigate and find their way around the document easily.
CSS should be used for presentation, and markup just for structure.
The tags and attributes that are no longer available are presentational in nature. CSS is better for presentation, as it empowers users by allowing them to override or completely disable the styles should they find them unusable. The web should be about interoperability, and presentational elements and attributes cannot be overriden by user-style sheets.
It's not; it's related to knowing what you're doing. If you're having problems with validation in an XHTML Transitional DOCTYPE, you're obviously still learning your craft. I don't mean that in a snotty way; everyone has to start somewhere, and there's plenty of scope for us all to learn more. This article assumes that people understand XHTML, and the topic is purely about choosing an appropriate DOCTYPE. An introduction to XHTML would be more appropriate for your question.
I don't follow this at all. If you know that one of the differences between HTML and XHTML is case-sensitivity, why would you think that because case didn't cause a problem in HTML, it wouldn't cause a problem in XHTML? It's a contradiction in terms.
There are two issues here. Firstly, the validator isn't a teaching tool. It's a tool to test whether or not something conforms to the appropriate DOCTYPE. If something in mixed case is flagged as an error in XHTML, someone competent in XHTML would know what to do. Secondly, the validator was created and is maintained by volunteers who give up their free time to help developers ensure their content is standards compliant. They don't have the endless resources that Microsoft have to develop this tool. With this in mind, the validator team have gone to great lengths to ensure that the error messages are friendly, and as simple to understand as possible, without generating a complete tutorial on every error they encounter.
Sometimes, it isn't someone else's fault that you're having problems.
Posted by Gez on