Harmless XHTML

Author: Ted Shaneyfelt

Abstract

Widespread misleading reports have spread fear of XHTML worldwide. The effort expended to propagate these reports could be better exerted in promoting education and adoption of best practices. Best practices avoid the dreaded pitfalls, while advancing technology.

Context

Ian Hickson has pointed out that an article has been circulating promoting the idea of sending XHTML as text/html as harmful since a post on his own web log as early as September 2002. This document is a response to his posting at the time of this writing. This organization follows the organization of his document, presenting responses to concerns as they appear in that document.

Executive Summary

You may use XHTML safely even if it will not be delivered with the application/xhtml+xml MIME type. You do not need to revert back to SGML based HTML4, abandoning well-formed XML standards to do so safely. The problems that are often pointed out against XHTML delivered as text/html are debunked below.

Although IE6 does not support application/xhtml+xml it is possible to follow good practices to workaround the problem until Microsoft addresses its problem.

Why Using text/html is Not Bad

Claims that text/html is inappropriate for XHTML documents are commonly misunderstood, and lead to stagnation of technology adoption. There are good reasons to adopt an XML based language like XHTML, mainly the ability to parse without name-based discrimination. XSLT, for example allows one document to combine content live from a number of other XML based documents.

My understanding is that this claim of text/html being a bad delivery mechanism for XHTML is mainly directed at webmasters. If you are a webmaster and you know that your documents are XHTML, you should serve them as application/xhtml+xml, and browsers should support them appropriately, though in practice, IE6 does not support application/xhtml+xml at all, so you're caught in a no-win situation. Rather than follow one vendor's path away from modern standards, let's move forward with the newer and more capable standards.

It seems to me that the casual reader typically misunderstands the claim from the author's perspective. As an author, if you don't know for sure that your page will be delivered as application/xhtml+xml, you are led to believe that you should not write XHTML at all. This misunderstanding has so permeated thinking in recent years that tool developers even on open source projects to follow the path away from modern XHTML to favor HTML4.

I have seen the illustration of an author attempting to write XHTML and publishing as text/html without learning best practices first, then later finding the problems with their code when publishing as application/xhtml+xml. This illustration is a better call to educate authors and develop better tools to promote best practices than an argument against XHTML. I expect that more harm in the form of stagnation has been caused by developers resisting XHTML altogether because of this misunderstanding than benefits from pointing out potential problems.

Good Practices to Alleviate Specific Potential Problems

The issues that have been pointed out that affect documents switched between text/html and application/xhtml+xml can be overcome by good practices.

Though the syntax for escaping script and style elements is unwieldy, it can be avoided altogether. My suggestion is to use external stylesheets and script files with the same name as the web page except for the filename extension. Such issues are not sufficient to justify abandoning XHTML altogether.
Issues like case-sensitivity should be learned by the author or tool developer and put into practice. Such issues are not sufficient to justify abandoning XHTML altogether.
Rather than asking coders not to use XHTML because they might misunderstand details of semantics, effort would be better spent documenting how to workaround the problems. The most common problems seem to relate to simple things like case-sensitivity, which are easily resolved by a proper understanding by the programmer. Educate programmers rather than abandon XHTML.
Where deprecated functions have been replaced, it's the coder's responsibility to learn the new functions. This issue does not affect documents that have no scripts, and even for those, there is a workaround. XHTML should not be abandoned on account of this.
Inconsistent error handling among various UAs processing text/html content is a legacy problem. It is not caused by XHTML, and is certainly not a valid excuse for abandoning the XHTML. standard.
XHTML documents are well-formed, so they often contain empty elements ending with "/>". Although a claim has been made that a UA could be developed display ">" characters and still be within standards, this seems to be a completely hypothetical argument. The World Wide Web Consortium seems to have considered current practice when they suggested placing a space before the slash, enabling legacy UAs to process XHTML documents as HTML. In this manner, it is possible to create an XHTML document that works perfectly fine with HTML UAs.

Copy and Paste

Misuse of copy and paste by authors is not a valid reason to abandon the XHTML standard or to prefer HTML 4 over it..

Why using XHTML with good practices is good even when sent as text/html

Arguments against sending XHTML have been made that don't apply to validated XHTML pages. The obvious solution is to validate the web pages as XHTML.

Although browsers may treat XHTML as Tag Soup when it's served as text/html, well written XHTML documents will render appropriately regardless of which interpretation is used.
XHTML will generate no XML errors if it truly is XHTML. Problems with documents that claim to be XHTML but are not are not good reason to abandon XHTML.
Whether a document is accessed via text/html or accessed locally on disk, good XHTML is well behaved whether or not it is treated as XML. Non-XHTML documents that are improperly labeled as XHTML are not a good excuse for abandoning XHTML.
XML tools parse XHTML without regard to the choice of names and attributes. SGML tools are at a disadvantage, because they require a complete document type definition. When an XHTML file has been isolated from its DTD file, XML tools like XSLT can still process it generically as a well-formed document.
There are real reasons XHTML should be preferred over HTML. For example, a change to a website can be done by subjecting the entire site to an XSL transform. In order to do this with HTML, the site must be tidied first, which may have problems of its own in the conversion. Also, XPath applies well to XML documents to locate any element, which is not as well defined for HTML 4.0 documents.

XHTML 1.0 Documents and HTML Compatibility

Making XHTML 1.0 documents work with HTML 4.01 UAs is addressed in RFC 2854 and also by the World Wide Consortium's Appendix C if the XHTML 1.0 Standard. A key step in the process of switching from obsolete HTML to XHTML is providing a migration path. The proposed practices do provide a migration path that serves existing HTML4 UAs and future XHTML UAs.Whether or not the resulting document is compatible with the HTML 4.0 standard and SGML is not the point. Rather, the suggested practice is compatible with HTML 4.0 UAs. It allows existing UAs to process XHTML documents as though they were HTML documents. In the practical world in which we live, this is an important concern, and it is adequate for migration to XHTML 1.0.

The " />" empty-element syntax is correct for XHTML documents, and it is also processed fine by the vast majority of HTML 4.0 UAs without any mythical extraneous ">" characters being rendered, contrary to widespread misleading commotion from naysayers.
Script and style elements can hide their content by making it external to the document, with the added advantage of making it available for sharing with other pages.
The xmlns attribute is ignored by the vast majority of HTML4 UAs, contrary to widespread misleading commotion from naysayers.
XHTML doctypes do not prevent HTML4 UAs from correctly rendering a well designed page.

How to Write XHTML Documents that Render Properly as text/html

Although the text/html mime type causes UAs to treat XHTML documents as tag soup, authors are not prevented from good practices such as validating XHTML documents. In order to achieve critical mass of valid XHTML documents, tools should assist in the generation of valid XHTML documents and prefer them as default over HTML4. Authors should also prefer writing and validating XHTML documents. Those authors who want to migrate towards XHTML should start by adopting WFHTML, but omit the namespace and doctype from pages that do not validate as XHTML. It is better for the author to settle for WFHTML without those features as the intermediate form than to declare them on a non-compliant document.
Since in some scenarios, XHTML cannot be automatically detected by sniffing or other methods, an important feature of XHTML is its ability to be parsed as either tag soup or XML. Documents should be written in such a way as to minimize effects of these parsing details.
Though a UA interprets an XHTML document as tag soup, documents should be well formed for the benefit of tools that parse only XML.

Advantages of XHTML

Although it is preferable to serve application/xhtml+xml rather than text/html to those UAs that can accept that mime type, some of the benefits are still applicable to documents served as text/html. Perhaps the most important benefit is the use of tools with XHTML. XSLT can be successfully applied to documents served as text/html, XSLT is an important tool that currently works with the most popular UAs to combine XML data from various sources with templates to display a resulting web page. This is in practice today, and has been working with Mozilla and IE. for years. Even IE doesn't seem to have any problems receiving a XHTML files as text/html and processing them as XML data in transforms.

Conclusion

There are few disadvantages in using XHTML. There is no need to throw out the standard with the bad practices. Adopt and prefer the XHTML standard, develop good practices, and only throw out the bad practices and migrate away from obsolete technology. Serving HTML documents with text/html is appropriate, and XHTML can be thought of as an XML encoding of HTML. Where pitfalls are encountered, use best practices to overcome them. Tool developers should encourage and assist in developing best practices rather than shying away from XHTML. In theory, and in practice, standards are important. In practice, if you're not ready to switch to XHTML, even nonstandard WFHTML is preferable over HTML 4.0. WFHTML sacrifices compliance with valid HTML to comply with a better standard of well-formed XML, while not necessarily meeting the standard of XHTML. But XHTML is preferable to both HTML4 and WFHTML. Valid XHTML that is written with best practices should be the preferred format for web pages, and it should be the default format for new HTML documents.

The problems with IE have known workarounds. Some groups (mozillaquest, for example) may have no desire to expend any effort to make their sites render correctly on IE. This is fine. When Microsoft makes a better browser, the problem will resolve itself, and until then, their browser will simply not render those sites correctly, and those webmasters who want their sites to be available to all can configure their servers accordingly.

I suppose most readers of Ian's document don't read his disclaimer in Appendix B.

Acknowledgments

Thanks to Ian Hickson for providing the motivation for writing this article. The organization and much of the content of this document is based on his writings.

Document made with KompoZer