Take the 2-minute tour ×

I'm refactoring a .Net web application that is in


Right now the approach is just to aim for the stars and go for the latest doctype just because it's latest, I would like to make a wiser choice and target a specific one and for good reasons.

There are similar questions existing but the answers might be outdated now.

What is the difference, advantages, disadvantages between standards and quirks mode, what are some quirks I may run into with differently set doctypes?

I have been told that an XHTML doctype is preferable to integrate AJAX since the UpadtePanel serializes it and to do so needs to have a XHTML do type, to what extent is this true?

And for browser compatibility, in which direction are browsers going in terms of DOCTYPE, is there a common thrend or do they differ?

share|improve this question
@Marcel Korpel: thanks for the extra info –  GenEric35 Jul 14 '10 at 21:22
I found the HTML5 validation plugin for Visual Studio it adds intellisence and property window for HTML5 element attributes. blogs.msdn.com/b/webdevtools/archive/2009/11/18/… –  GenEric35 Jul 15 '10 at 13:38
add comment

5 Answers

up vote 14 down vote accepted

HTML5 doctype, which is

<!DOCTYPE html>

XHTML is largely dead as a standard, and never was implemented correctly in most cases.

share|improve this answer
The W3C is hardly an impartial third party. They wrote the freaking spec, and they still love them some XHTML and push it every chance they get, but they pretty much doomed it with 2.0. (Not backward compatible? WTF, y'all.) XHTML 2.0 is probably a huge part of why there even IS an HTML 5. –  cHao Jul 15 '10 at 18:47
@Rob: Most XHTML is actually served as text/html and therefore parsed as HTML (NOT XHTML). If you serve it correctly you may find that what you thought was valid XHTML no longer works because it depended on the leniancy of the HTML parsing. XHTML had benefits, but was also extremely fragile (and, despite what DOCTYPEs say, it is used very little)--leading to it being a largely dead standard. –  STW Jul 15 '10 at 20:54
@STW - Despite misuse by amateurs and the unknowing, XHTML is alive and well for those of us who know how to use it. The real problem is with Internet Explorer, as everything on the internet is, not XHTML, since IE is the only browser that does not work with it (or much of anything else for that matter). –  Rob Jul 15 '10 at 23:26
@Rob: about Internet Explorer, it's not compatible with XHTML? is it that it can't interpret markup that complies to XHTML or it's the use of a XHTML doctype that breaks something, because I have noticed the layout of my pages getting messed up when I changed the doctype to XHTML, and had to do alot of fine tunning espcialy removing attributes from HTML elements and replacing them with CSS either inline or in a external file –  GenEric35 Jul 16 '10 at 13:39
XHTML is dead, Jim, but not as we know it. –  Dave Van den Eynde Sep 7 '10 at 8:44
show 4 more comments

Any Doctype:

  • HTML 4.01 or XHTML 1.0
  • Strict or Transitional

served as html (not html+xml) should be OK. There's no such thing as a better doctype, you just have to choose one filling your needs and then stick to its rules.

  • Avoid Frameset, but if you've to, use the title attribute to describe the role of each frame to a screen reader user (same with iframe btw).
  • Quirks mode (no Doctype) is a PITA, avoid it at all cost. This was OK 8 years ago.
  • No XML prologue unless you're serving html+xml (good luck with that! If you like complicated things when it's not needed, that's your choice)
  • If you are forced to use attributes that are forbidden in Strict mode (target="_blank" for example) than use Transitional mode: this is why it was created! And please indicate to your users that the link will open in a new page, whether in the text of your link or in its title. This is important from an accessibility point of view.

HTML 5 is the next big thing, we're waiting for it but as long as it won't work in every browser (I mean IE without JS) it's not advisable to use it in "serious" public sites. Is it even a Draft? What if entire part of it are rewritten in a couple of months?
My web agency uses it for its website but we won't use it on a client site anytime soon: it's just too soon.

Sidenote: I often see catch phrases like "a modern website in HTML5 and CSS3" implying that CSS3 is made for HTML 5. CSS3 has nothing to do with HTML5 and can already be used, as long as it degrades gracefully on old browsers.
You can design HTML5 with CSS2.1 or HTML4.01 Transitional with the latest CSS3 animations that only work in webkit nightlies, no problem.

share|improve this answer
+1 thanks for the practical examples Felipe –  GenEric35 Jul 15 '10 at 14:01
Serving XHTML as text/html is a bad idea--but unfortunately a hugely common problem. Serving it as HTML leads to browsers using their HTML rendering--and valid XHTML isn't necessarily valid HTML. For example, a self-closing <div/> is valid XHTML but invalid HTML (it parses it as "DIV/". Placing a space before the '/' (<div />) is a hack to let it be valid XHTML and quasi-valid HTML (the parse treats the '/' as an invalid attribute and ignores it. –  STW Jul 15 '10 at 20:56
@STW Trailing slashes are no longer invalid HTML - they're perfectly valid. The space hack is purely a legacy SGML measure, but HTML has moved on from SGML at this stage. –  lucideer Jul 16 '10 at 19:18
add comment

The new thing is HTML 5.

<!DOCTYPE html> is what you use to specify it. That's it. No DTD name or URL or whatever.

If you're using something that likes XML, like .net, then you might want to use XHTML. But don't do it for any other reason; XHTML never was really popular as a standard, or at least it was almost never used correctly.

share|improve this answer
+1 for .Net considerations, this is indeed a ASP.Net 3.5 application with some WCF calls made from the Web app, and some AJAX.The app is likely to migrate to ASP.Net 4.0 soon. I am trying to find the implications of XHTML for .Net, so far I heard only rumors about it being required for AJAX, do you know of any specific XHTML requirements or benifits for .Net? –  GenEric35 Jul 15 '10 at 14:21
@GenEric35: I'm not sure about how required it is, but i do know Visual Studio really, really wants your code to be XML. I also read somewhere that there are a couple of controls that don't mind unclosed elements, which implies to me that almost all of them do. As long as you close your tags, it shouldn't matter much -- but ASPX tags are pretty much XML, so you may as well just go with XHTML and save yourself a bunch of hassle. –  cHao Jul 15 '10 at 18:33
add comment

Whatever you choose, make sure your MIME-Type is compatible with your DOCTYPE

The browser will use the MIME-Type (the HTTP Header ContentType) to determine how to treat your page. For example: A DOCTYPE of XHTML 1.1 Strict served as ContentType Text\HTML is parsed as HTML.

DOCTYPE is important, but largely irrelevant if the wrong ContentType is used.

share|improve this answer
I'm not 100% sure what you mean by your emboldened comment - all (valid) DOCTYPEs are compatible with both text/html and application/xhtml+xml (and other content-types). A DOCTYPE of XHTML 1.1 Strict served as text/html is a valid polyglot (provided the markup validates obviously). –  lucideer Jul 16 '10 at 20:36
add comment

Browsers have never actually used DOCTYPE to determine the markup language of your document (they use HTTP Content-type instead), so which DOCTYPE you chose was never hugely relevant - just as long as you are using a valid DOCTYPE of some description. Whichever you choose is up to you.

If you're writing HTML, <!DOCTYPE html> is the shortest to type, and puts all browsers into standards mode (which is what you want).

If you're writing XHTML, <!DOCTYPE html> is also perfectly legitimate (XHTML actually requires no DOCTYPE at all, as it relies entirely on HTTP Content-type, but there's no harm putting a DOCTYPE in for portability.

Don't use <!doctype html> - while this is technically valid HTML, it's invalid XHTML so will break if you ever try to parse your page as XML.

Slightly OT sidenote: Some people here have commented that XHTML is a "dead" standard - this is false. XHTML has been integrated into the upcoming HTML5 spec. The spec is entitled "HTML5: A vocabulary and associated APIs for HTML and XHTML"


share|improve this answer
Not true at all. Absence of a doctype puts browsers into quirks mode. hsivonen.iki.fi/doctype –  Rob Jul 15 '10 at 18:06
@Rob Where did I say to exclude DOCTYPE? I explicitly said in the first paragraph that you DO need a valid doctype. Sorry if you mis-read my post, but nothing I said is untrue. –  lucideer Jul 15 '10 at 18:21
@lucideer - I'm contesting that you said a doctype is not used to determine the markup language and evidence of that is my example. However, re-reading that paragraph, I see you didn't say what I was more alarmed about; that people might think you were saying the doctype is not important. –  Rob Jul 15 '10 at 19:06
+1 -- lucideer is exactly right on this -- ContentType takes precedence, of course a fun fact is that IE 6/7/8 only quasi-supports XHTML: w3.org/MarkUp/2004/xhtml-faq#ie –  STW Jul 15 '10 at 20:51
@STW - except lucideer is wrong. reference.sitepoint.com/css/doctypesniffing Content type does not determine standards mode and having the wrong doctype can still trigger quirks. Also, IE has zero support for XHTML despite any trickery to make it work. –  Rob Jul 16 '10 at 11:33
show 7 more comments

Your Answer


