which doctype?

Hi,

I am a novice web designer and would really appreciate some advice on doctypes.

I believe that all my code conforms with xhtml standards and so that (xhtml 1.0) would seem the obvious choice but should I go with strict or transitional? I see both are commonly used. I would imagine that strict would always be the best option but under what circumstances would transitional be more appropriate? I've heard that script and ajax require the latter. Is this true? is there a checklist of webpage content to consult which determines the best to use?. Is there ever a reason to use html 4.0 if my code conforms to xhtml standards?

Thank you

A few very good articles from Roger Johanssons' blog might help you make this decision.

But ... I'll tell you this... always code STRICT. Whether you choose to go XHTML or HTML (I tend to prefer HTML STRICT lately), that's up to you.

Hi Karinne,

Yes I would always want to use strict to avoid quirks mode but can I ask why you choose html rather than xhtml?

Thanks a lot

Hmmm, why did you decide to use HTML Strict and not XHTML Strict? Just wondering?

Bah .... the main thing is that you use a STRICT doctype. HTML or XHTML ... it doesn't really matter.

The original reasoning behind the XHTML doctype was to server pages as application/xhtml+XML but not many browsers support it so ... what's the use?

And I agree with this totally.

I agree with Karinne. Here's how I characterise the different options:


Strict or transitional?

Transitional is intended as a stepping-stone from horrible code ("tag soup") to clean code. It's a good choice if you find Strict too difficult at the moment.

Otherwise, choose Strict. Strict forces you to drop many bad old coding habits.


HTML 4.01 or XHTML?

While you should definitely choose Strict if you can cope with it, the choice between HTML and XHTML is more of a personal preference. I think HTML 4.01 Strict is a better choice for most people; here's why:

XHTML was meant to be "the future of the web". The W3C have two purposes for XHTML:

• They envision it as a stepping-stone to XML, and integrating XML with XHTML. In the future, this may mean greatly improved interoperability between all sorts of devices, and other cool stuff such as modular inclusion of other markup languages (mathML is a current example).
• They want to use it to force web designers to write better code. In true XHTML (not the pretend XHTML that everyone uses), any parsing error is fatal.

Neither of these goals has been achieved in the slightest. The genuine adoption of XHTML has been almost totally obstructed by Internet Explorer's inability to understand it, and almost all XHTML web pages fail to validate (just like almost all HTML pages).

XHTML may be the future of the web, or it may not. So far we've seen little progress. The movement for HTML 5, however, is gathering force. HTML 5 is being developed by a different standards body, WhatWG. Here's how they describe themselves:

So whatever everyone may tell you, it's not clear what will be the future language of the web. There are currently two heavyweight standards organisations developing different standards. WhatWG are trying to work with W3C, and ultimately defer to them; nonetheless, the future of the web is not entirely controlled by W3C, but also by browser vendors. It's a complex relationship.

Furthermore, the XHTML 2.0 draft is deliberately not backwards-compatible with XHTML 1.0 or 1.1. Many designers write XHTML because they want a smooth transition to future standards; this isn't likely to happen.

What is clear, however, is that XHTML makes your life harder. You have to serve it to Internet Explorer with a MIME type of "text/html", which means that IE treats it as invalid HTML and uses error-correction routines instead of simple standards. You can serve it correctly to other browsers, but you must arrange content negotiation. When Mozilla receives genuine XHTML, it can't render the page incrementally and so you will see nothing until the entire page has been loaded (this is a bug, and is fixed for Firefox 3).

Also, Google ads won't work in XHTML without further work-arounds. Sites with user-posted content have trouble too, because a single invalid character in one user's post can break the entire site. Again, there are workarounds.

Is it really worth all that effort just to practise using a standard that might be useful sometime in the future? Or it might not: HTML 5 might steal XHTML's thunder.

If you have some practical need for XHTML right now, such as writing MathML, then go for it. But otherwise, it's a lot of work for little or no reward.

If you have a desire to write stricter code, then just write HTML 4.01 Strict. HTML is the best-supported language on the web, and has the longest record of widespread use. It's not "out of date" or "yesterday's language", and there's no reason to believe browsers will stop supporting it (almost the entire web is written in some version of HTML, and the HTML 5 draft is backwards-compatible with 4.01).

You can even use lower-case tags and closing </p> and </li> tags (I do), although the HTML validator, unlike the XHTML validator, won't enforce this.

Thanks everyone for your feedback. That was a really interesting post Mike, I appreciate you taking the time to explain things in such detail. It's certainly made my mind up that html 4.0 strict is the way to go.

If you want to really go all out you could use xhtml strict as application/xhtml+xml and use a content negotiation script to serve that as text/html to browsers that don't support proper xhtml properly. This way when better browser support comes in, all you have to is change a php file. Simple.

It really doesn't matter whether you choose html or xhtml though. Just go strict as has already been said.

Pete.

Nice post Mike!

I've now written a detailed article about this subject.

Mike is there a different validator that you use for HTML 4.0 Strict other than the w3c's validator?

That was an interesting article Mike.

I only started learning coding in February of this year and I basically went straight to XHTML 1.0 Strict because I believed it to be the best preparation for the future from what I had heard, which I now understand isn't necessarily true.

So if I accept what you say that HTML 4.0 Strict might be better, then what do I need to do differently? XHTML is all I know. Even after reading your article, and some of the things you linked to, I'm still a bit confused about the real differences between the two. I understand about XHTML requiring that all tags are closed properly and that things are nested correctly and that lower/upper case makes a difference, but none of those things would stop it validating as HTML right? What are the aspects of XHTML that can cause problems?

Also, if you have a chance, could you explain parsing errors, I hear about them from time to time but don't know what they are!

XHTML is a bit harder to implement than HTML. As far as I'm aware valid XHTML 1.0 strict will validate as HTML 4.01 strict, for the most part, but the opposite is not always true.

I advocate the use of whatever markup language suits the current project but as a rule I go for XHTML 1.0 Strict. I don't find it difficult to implement and standards aware developers who know their code shouldn't either. I can't see what is difficult about it. I can code a page in XHTML just as easily as I can in HTML though I will admit XHTML does demand more of you.

Another point about the jump to XHTML 2.0. This is a way off yet but after reading through the draft a few times I can only say that I am excited by the possibilities and the proposed changes. I also think that the leap will not be a difficult one for competent coders who are, again, aware of standards. If people are going to code without thinking about accepted standards or the integrity of their code then they are always going to struggle with big changes and XHTML 2.0 does look like it will be quite a big change when it comes along. That said I am looking forward to see what HTML 5 can offer the web as well. Whatever way you look at it the future looks bright and the more these standards are developed the better the web will become, providing designers and developers (both web and software) adopt them. I have my reservations about two competing languages. They are not really competiing languages, they have different applications, but there is always the danger that they could become this in the future.

In all honesty though, as long as you are using a widely supported and accepted standards then you are on the right track but there is certainly no danger in researching the different languages and making an active decision on which is the one for each different project. I believe at some time in their development every developer should come to this stage. I am not against someone using, say, XHTML 1.0 Strict just because that's what they were told to use and they know it's quite well supported, but it isn't ideal in my eyes.

Check out the respective specs, do a bit of research and form your own opinion, come to your own decision. There are advantages and disadvantages to both that's why there is such a divide. There isn't really a correct or an incorrect languauge to use. My decision, as I have stated, is usually on a project by project basis.

Pete.

As I see it, "preparation for the future" is a non-issue. XHTML is neither better nor worse than HTML in this respect.

If you're already using XHTML 1.0 Strict with no problems, then you have nothing to worry about. But you may find using XHTML makes your life difficult for some projects.

In coding terms, there's little difference between them. XHTML has a few extra conventions you must follow (such as lower case tags), that's all.

Again, it's not so much that HTML 4.01 is better, but rather that XHTML gives no advantages and can cause problems.

Strictly speaking, XHTML "backwards-compatible" self-closing tags are invalid HTML: <br /> should be treated as <br>& gt; (no space) by conforming user agents. Or so I am led to believe.

A parsing error occurs when the author makes a mistake with the formal structure of the language. For example, incorrectly nested elements: <p><em></p></em>. Or missed closing tags: <p>One paragraph <p>Another paragraph.

HTML (or XHTML served as HTML) is forgiving of these errors: the browser will try to correct them. In true XHTML, simple mistakes like these will completely break the page (you get a parsing error instead of a web page).

You can see this in action if you experiment with the correct MIME type "application/xhtml+xml". Make an error, and see what happens. In IE, of course, it will break even if the code is valid.

I just use the normal W3C validator (although I have its syntax checker running constantly in the background, so I rarely need validate "manually" at the W3C site: firefox html validator). In the course of writing that article, however, I came across the possibility of validating off-line using a custom DTD.

I haven't tested this yet (it will be an effort to set up), though I'm pretty confident it should work. There's little need for it, but it's there if you really want XHTML-style strict error checking for your HTML.

Ok, thanks for clarifying Mike, I'll keep doing what I'm doing for now then unless I run into any specific problems.

Perhaps I should amend the article.

I don't want to give the impression that XHTML is wrong -- merely that it's no better than HTML, and can cause difficulty in some situations.

In fairness, I think you do basically say that in the article already, but my confusion was really over what those potential problems/difficulties are. I think I'll continue coding as I have been but maybe declare the doctype as HTML 4.0 Strict, thus avoiding the potential problems - I think that's what you meant by 'XHTML served as HTML' right?

No. If you're writing XHTML, use an XHTML doctype. MIME types are not the same as Doctypes.

To serve XHTML as HTML, you change the MIME type to "text/html":

Code: Select all

<meta http-equiv="content-type" content="text/html; charset=utf-8" />

(You don't have to use UTF-8.)

The reason I don't like XHTML served as HTML is that it's no longer XHTML.

Yet this is the best way to serve your documents, if you want to avoid potential problems. Why? Because you're really using HTML, which is forgiving.

It's when you serve XHTML with the correct MIME type that things start to go wrong:

Code: Select all

<meta http-equiv="content-type" content="application/xhtml+xml; charset=utf-8" />

This is real XHTML: the browser will interpret it as XHTML. If you serve this to any browsers, then watch out! Your code had better be valid, or the site breaks. Even if your code is valid, user-posted content will probably break the site, and so will google ads (although there are ways to fix these problems).

When you serve XHTML as "text/html", browsers will interpret it as "tag-soup", and apply their error-correcting routines.

The good news is that browsers are very good at correcting errors. The errors in your code will be very small, so the browsers should have no trouble correcting them.

To my mind, however, it makes more sense to serve valid HTML, which the browsers don't need to correct. But that's more a stylistic decision than a practical one.

Oh, ok, in actual fact I was using the text/html MIME type, so I was serving XHTML as HTML without realising it! Sorry I'm being so slow to grasp all this, I think I've got it now though. You're very patient and good at explaining things in different ways, thank you.

You're not being slow at all. I had no idea about this until I stumbled across some articles -- while in the process of trying out XHMTL. It's totally counter-intuitive. It took me quite some time to wrap my head around it.

So the "correct" way to serve XHTML is as "application/xhtml+xml". This is what you do if standards and validity matter more than anything else.

But the most practical (the easiest/safest) way is to serve it as "text/html".