Why put an XHTML doctype declaration on HTML files? What does that do?

Question

I wonder about the number of web pages I encounter that are HTML files, but that wear an XHTML DOCTYPE declaration.
Why are people doing this? What do they hope to achieve? Why not reserve the XHTML doctype declaration for actual XHTML files?

Or am I missing something?

Edit: there is some confusion about what "actual XHTML files" are; to demonstrate that the difference is not caused by the DOCTYPE declaration, compare this file to this one. The first is HTML, the second is XHTML, although the contents are identical; only the file types differ. Both display fine in compliant browsers, but the first one is parsed with the HTML parser and the second one with the XML parser.

Answer 1

Why put an XHTML doctype declaration on HTML files? What does that do?

All that does is tell markup validators that they're about to validate an XHTML document, as opposed to a regular, SGML-rooted, HTML document. It describes the content, or more specifically the markup that follows, but nothing else.

Why are people doing this? What do they hope to achieve? Why not reserve the XHTML doctype declaration for actual XHTML files?

Or am I missing something?

Kind of. What actually happened was that people weren't aware that just putting an XHTML doctype declaration on top of an HTML document didn't automatically transform it into an XHTML document, although admittedly that was what everybody was hoping for.

You see, most web applications out there aren't configured to serialize XHTML documents as application/xhtml+xml properly, instead opting to serve pages as just text/html. (It's typically because of the .html file extension more than anything else, really; generally speaking, servers do correctly apply application/xhtml+xml to documents with .xhtml or .xht as the extension, but only static sites that actually make use of the file format will benefit from this.) That leads browsers to decide that they received a regular HTML document, and so that tag soup parsing nonsense we've all come to know and love inevitably ensues.

Note that it doesn't matter even if you have a meta tag like this on your XHTML document:

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

Browsers will ignore that, and only look at the actual HTTP Content-Type header that was sent along with the XHTML document.

To make matters worse, Internet Explorer, being the most-used browser in the past few years in XHTML's heyday, never properly supported the application/xhtml+xml MIME type before version 9 was finally released: instead of parsing the markup, constructing the DOM and rendering the page, all it would do was ask for a file download. That doesn't make a very usable XHTML page!

So, guess what we all had to live with until HTML5 became cool?

This, along with things like IE6 going quirky on pages with the XML declaration before the doctype declaration, is also one of the biggest factors leading to XHTML's downfall (along with XHTML 1.1 never gaining widespread usage, and XHTML 2.0 being canceled in favor of HTML5).