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.
(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.
Based on Testing and Research (October 25, 2003)
Our October 2003 website statistics yielded the following useful information:
idattribute; they require the
nameattribute instead. They also do not support the
Qelement, but our special script makes it work just fine on Internet Explorer.
ACRONYM. A few other phrase elements are supported by some but not all. Moreover, they don’t support the entity codes for curly quotation marks either (they will display the
”as text instead of rendering the marks), so they’re better off getting no quotation marks at all (which is what happens with
application/xhtml+xml(Opera 6 and 7 can also understand it, but they don’t send that information in the
HTTP-ACCEPTheaders, so they receive our pages as
What this means for our purposes is this:
nameattribute could simplify the markup, but since it would foul up 1.13% of Internet devices in current use, the cost in terms of interoperability isn’t worth it. In the future, the number of older browsers will likely decrease, but mobile device usage is definitely on the rise. Therefore, we consider it imperative to use both attributes (
idis required in XHTML) in link targets.
Qelement instead of the longer entity codes for curly quotation marks, will ensure cleaner markup. It will work properly on 99.11% of Internet devices in current use; another 0.07% are better off getting no quotation marks at all than to get the curly ones. Both percentages are likely to increase in the future. Our choice to use
Qbecomes a no-brainer! (Not so: see Version 10.6 below.)
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
prologue throws Explorer into quirks mode, and voila! no more
?xml prologue and the
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:
mod_rewritemakes this possible)
The version number changes whenever all (or most) pages of the primary domain are edited.
mod_rewritemagic. Entire domain is now written in XHTML 1.0 Strict for the first time.
Qelements on ookingdom.com back to manual curly quotation marks (“ ”). Switched all
ACRONYMand removed altogether any such tags that were not expanded with a
titleattribute. Removed browser compatibility notice on the Home page, as it is no longer necessary.
This change has been in the works for quite some time, as seen in these News Archive posts:
ACRONYMtags, because of the flickering problem.
Qelement was considered less critical than
ACRONYM“since manual quotation marks are semantically identical to the use of