Final Edit

November 24, 2003
Last Updated May 16, 2006

1/12/2022: This page is old and somewhat outdated; it remains here for archival purposes, and for a bit of site history (below).


After all was said and done, I decided to stick with XHTML for this site. My observations and arguments appear on this page along with a list of additional improvements to the site.


Dealing With My Own Arguments

(answer to “Oops! Dead End”)

Forward compatibility was rejected as a reason for using XHTML. I still agree with this. Who knows the future? In the light of history, this is not even a valid consideration. Let’s work for the present time.

Serving XHTML as text/html to most existing user agents makes sense because this is the only way they can parse it. As for sending them “invalid HTML,” technically this is correct, but in practice, existing browsers are designed to parse tag soup, so it makes no difference. At any rate, the W3C engineered XHTML to work like HTML in existing user agents by using the same elements and attributes in both. That is why they were able to write HTML Compatibility Guidelines for XHTML. Enough said.

As I mentioned on another page, even Hixie states (in Appendix B of his text document) that serving XHTML as both MIME types is okay if you know what you are doing.

MIME Type Options Examined

Serve only HTML as text/html
Right for 95% and okay for the rest, but not forward thinking
Serve only XHTML 1.0 as text/html
Works for all but defeats the purpose of XHTML
Serve only XHTML as application/xhtml+xml
Works only for 5%—the rest cannot access the site at all
Serve only XHTML as either MIME type depending on the browser
Works for all and addresses the issue of XHTML support (this was our choice)
Serve PHP files as either HTML or XHTML depending on the browser
Works for all and addresses issues, but changing file extensions breaks old links. Also, server-side scripting delays page loading
Serve either HTML or XHTML via content negotiation
Works for all, addresses issues, and links are okay—but twice as many documents must be maintained. Also, content negotiation is not usually available under shared Web hosting

The NAME Attribute, the Q Element, and XHTML

Based on Testing and Research (October 25, 2003)

Our October 2003 website statistics yielded the following useful information:

What this means for our purposes is this:

A Hidden Advantage to Using XHTML

I discovered partway through the conversion from XHTML back to HTML that I was now getting horizontal scrollbars in Internet Explorer (curse Microsoft!). Previously I had thought that one of my scripts was fixing the problem; apparently I was wrong. Internet Explorer’s “standards-compliant mode” is what was causing the scrollbars. The ?xml prologue throws Explorer into quirks mode, and voila! no more scrollbars.

Both the ?xml prologue and the ?xml-stylesheet PIs are optional. If I use the former but not the latter, and serve MIME types according to the browser in use, everything should be okay.

There were other reasons for sticking with XHTML:

  1. Most of the site was already written in it.
  2. Suppose that at some future time, we decide that XHTML is the way to go. It is easier to simply keep it in XHTML now than to convert twice as many pages later.

Other Considerations

More Site Improvements

The version number changes whenever all (or most) pages of the primary domain are edited.