encyclo - 1:38 am on Apr 3, 2006 (gmt 0)

DrDoc:

XHTML served as text/html is truly "HTML 4.01 in quirksmode"

Well, to be fair, a document with an XHTML doctype is parsed in standards-compliance mode rather than quirks mode (except in IE6 when preceeded by an XML prolog), but it is true to say it is parsed as "HTML with errors" (the undefined attributes which constitute the trailing slashes).

The validator won't complain about XHTML served as text/html for two reasons, firstly that the file is merely being checked for conformity to a published DTD rather than whether it is being correctly served, and secondly that at least for XHTML 1.0 (not 1.1), text/html is explicitly permitted as an acceptable MIME type for legacy use.

DrDoc:

Saying that "it's ok to send XHTML as HTML 4.01" simply because no browsers have implemented shorttag minimization is dangerous. You are now relying on a browser bug to get your documents to render correctly. I, for one, hope that the Gecko engine will fix this problem and implement shorttag minimization properly, in order to be more fully HTML 4 compliant.

They will never do it, simply because it will break legacy XHTML 1.0/text/html support (which is specifically permitted by the XHTML specification). The SHORTTAG problem is a non-issue because user agents have never been SGML-compliant agents, and because a significant number of XHTML 1.0 documents exist whereas no HTML documents which use SHORTTAG notation exist precisely because there has never been an user agent support.

Robert Lofthouse:

Unfortunately, I believe that everyone just ran to XHTML without thinking about the consequences. It was the latest thing, all the standards gurus were going on about it, but nobody really took the time out to see how this new markup language worked, and what affect it had on other technologies.

Firstly, welcome to WebmasterWorld Robert, and thank you for your input! I think there has been a shift in the message carried by what we can generally call "standards evangelists" over the last couple of years for serveral reasons. When the XHTML specifications were published, they were seen as a great leap forward from the prevalent "tag soup" HTML. There was an assumption that the tools and browser support would rapidly follow, and that XHTML would push HTML into obsolescence.

I count myself in this group, and I was already producing XHTML documents served as application/xhtml+xml back in 2001/2002 which functioned in early Mozilla pre-release builds. But the tools and browser support never followed, IE7 still will have no support for XHTML. We misread the future.

The second failure of XHTML was with the implementation - the specification itself is flawed-to-broken. In almost every case of even very experienced developers putting in place a "true" XHTML solution for a public (not test) website, the difficulties and disadvantages of using application/xhtml+xml far out-weighed the supposed advantages. Most if not all early adopters walked away.

The message from standards evangelists is much more mitigated than in the early days. There was a great deal of "HTML is eeeeviiiil" and "tables are eeeeviiiil", and a certain utopian feel to the refrains. But I think it is now a mistake to suddenly switch to a "XHTML is eeeeviiiil" discourse which is equally uncompromising. The idea is not (as in the early days) to assume that HTML is going to disappear rapidly from the scene and be replaced by XML variants. Rather it is more important to to consider "now-compatibility" rather than "forwards-compatibility". We messed up predicting the future so let's talk about what you should be doing here and now to produce robust, well-built, compatible websites.

If you are building a site today, HTML 4.01 Strict is the best choice, as it has the best user agent support, has the advantage of legacy support too, is easiest to parse and render by the widest variety of browsers and search-engine spiders today.

XHTML 1.0 served as text/html is overall a safe choice too. The HTML mime type ensures legacy support, the trailing slash problem is far less serious than the vast majority of real tag soup invalidity, many tools now produce XHTML-compatible syntax by default, and the doctype ensures standards-compliace rendering mode in modern browsers. It is also an easier standard to understand than HTML 4.01 as it is based on the simple constructs of XML syntax rather than the arcane rules of SGML.

Is XHTML ideal? No, but then using tables for layout isn't either, but surely we should pull back from standards extremism and suggest a more pragmatic approach to standards compliance?

A useful reference guide to XHTML from the W3C is: HTML and XHTML Frequently Answered Questions [w3.org].