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:
- 0.24% of our traffic came from Internet Explorer 4 (all versions)
and 0.82% from Netscape 4 (all versions). Neither of these can find
a link target by its
idattribute; they require thenameattribute instead. They also do not support theQelement, but our special script makes it work just fine on Internet Explorer. - Additionally, 0.02% came from earlier versions of IE and Netscape, and 0.05% came
from PDAs and
cell phones. None of these devices can find link targets by their
ideither. - Very old browsers and mobile devices don’t support
Q,ABBRorACRONYM. 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“or”as text instead of rendering the marks), so they’re better off getting no quotation marks at all (which is what happens withQ). - The world’s best browsers (Netscape 5, 6 and 7; Mozilla,
including Firebird and Phoenix) accounted for 4.92% of our traffic.
These browsers can understand XHTML
when properly served as
application/xhtml+xml(Opera 6 and 7 can also understand it, but they don’t send that information in theHTTP-ACCEPTheaders, so they receive our pages astext/htmlinstead).
What this means for our purposes is this:
- Dropping the
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. - Using the
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 useQbecomes a no-brainer! Not so: see Version 10.6 below. - Properly served XHTML will speed parsing for the 4.92% of browsers that receive it and can understand it. This makes it worth our while to use it, since that number will likely grow in the future.
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:
- Most of the site was already written in it.
- 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
- Use clean URIs (
mod_rewritemakes this possible) - Use semantic phrase elements (JavaScript makes this practical)
- Keep the subdomains (designs and statistics are kept separate)
More Site Improvements
The version number changes whenever all (or most) pages of the primary domain are edited.
- Site Progress
(Version 10.1, November 5, 2003) — cleaned up URIs using some
mod_rewritemagic. Entire domain is now written in XHTML 1.0 Strict for the first time. - More Fixes on This Site (Version 10.2, November 10, 2003) — improved rendering on IE 5.
- Design Update
(Version 10.21, November 12, 2003) — improved rendering
on IE 4; reversed order of
entries on all News Archive pages; special styling for
dfnelements. - Bye Bye Digital Home (November 18, 2003) — site subtitle changed to something more meaningful. At this time I also revised the Home page layout and added the UTC time stamp near the top of the page.
- More Site Updates (Version 10.3, November 23, 2003) — improvements to the navigation bar.
- Presentation Themes Fixed (Version 10.4, November 29, 2003) — the look and feel of the site can be changed to any of four themes, from any page on the primary domain (the Umm themes were added on December 2). The themes work on Internet Explorer 4 or higher; Netscape or Opera 5 or higher; Mozilla and other standards compliant visual browsers.
- Netscape 4 Gets Presentation Themes (December 9, 2003) — only Pastels, Kittens, Umm Backgrounds (light colors only) and Minimalist are available. Dark Colors and the dark color Umms are not. Another theme was added the next day.
- Navigation Bars Cleaned Up (Version 10.5, December 11, 2003) — access keys for Search, Site Map etc. are now identified by a number in parentheses. This required another editing of the page markup.
- Latest Addition and Design Tweak (Version 10.51, January 13, 2004) — the Categories section of the News Archive was added. Bits of markup, scripts and style sheets were updated. The browser compatibility notice on the Home page was added at this time.
- IE Fix Completed
(Version 10.6, February 3, 2004) —
Converted all
Qelements on ookingdom.com back to manual curly quotation marks (“ ”). Switched allABBRtags toACRONYMand removed altogether any such tags that were not expanded with atitleattribute. 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:
- Automated Accessibility Verification Considered Harmful (November 5, 2003) — concern was expressed over the flickering caused by the script running on Internet Explorer.
- What’s Going On
Here? (January 8, 2004) — decision was made to switch
back to manual curly quotation marks and
ACRONYMtags, because of the flickering problem. - It Stands Once Again
(January 8, 2004) — decision was made to keep the script,
but use of the
Qelement was considered less critical thanABBRandACRONYM“since manual quotation marks are semantically identical to the use ofQtags.” - Another Rebuild in the Works (January 28, 2004) — the double image loading and flickering was deemed “unacceptable,” paving the way for a new version which is still under construction at this writing.
- Stick a Fork In It—It’s Done (Version 11, March 17, 2004; read also March 18 entry) — Design issues included dropping the XML prologue to allow IE4/Mac to display our pages and allow IE6/Win to render pages in standards-compliant mode, and excluding Netscape 6 from receiving our pages as XML so it would run our scripts properly. Additionally, two sections of the site were renamed; style themes were revised; a new Contact page replaced the old email links; Ummamum’s Surprise was fixed to work properly on most browsers; the “Jump to navigation” link was made available to most browsers by using access key j.
- Version 12 Completed (May 21, 2004) — The entire domain was converted to PHP format. Doctype and MIME type are tailored to the browser in use. Entity codes for special punctuation marks are switched to plain marks for browsers that cannot understand the entity codes. A special style sheet is given to WebTV. Site maintenance is greatly simplified, thanks to modular internal structure.
- New Design Tweak: Version 12.01 (October 1, 2004) — Just a few style and scripting changes, and accompanying informational updates.
- Say Goodbye to the Style JavaScript (Version 12.1, November 20, 2004) — Client-side scripting to serve style sheets was replaced by server-side scripting to speed up page rendering. The News Archive was partially restructured ten days earlier.
- The Oo Kingdom Version 13 Completed (Version 13, February 17, 2005) — improved navigation, styling and server-side scripting; friendlier fonts and colors.
- If It’s Broke, Fix It (Version 13.1, May 16, 2006).
- Version 14 Unveiled (Version 14, November 13, 2007).
- Broken Website Layout Fixed (Version 14.1, February 9, 2008).