While studying the configuration options of the proxy cache Squid, I stumbled over this gem of a comment:

#    Squid will write the Referer field from HTTP requests to the
#    filename specified here.  By default referer_log is disabled.
#    Note that "referer" is actually a misspelling of "referrer"
#    however the misspelt version has been accepted into the HTTP RFCs
#    and we accept both.

Ruby on Rails seems to do its best to push developers towards XHTML. Every generated scaffold is marked up XHTML-style and all the useful helper-functions produce valid XHTML. But in spite of this, I think it is worth thinking twice about which doctype to use.

It is still not a very well known fact, but Internet Explorer has no real support for XHTML. It will happily display pages with XHTML doctypes, as long as they are fairly compatible with HTML, but it will use its ordinary rendering engine and just think about XHTML as a slightly weird form of HTML.

Firefox , Opera and Safari will think the same about the XHTML documents sent from a standard Rails application, but in contrast to IE these two browser actually have real support for XHTML documents, you just need to tell them to use it. The way you tell them that, is by setting the content-type in the HTTP-headers to 'application/xhtml+xml'. Do this, and suddenly XTHML supporting browsers will no longer think about your website as a big soup of tags, but as XML that better be well-formed and computer-readable.

XHTML Problems

As long as you keep serving XHTML as ‘text/xhtml’, it easily seems like the only difference between good old HTML and the doctypes with a X in front, is just the required lowercase and the closing of all tags. But start pushing XHTML supporting browser to use their XML rendering engines, and the differences will suddenly become far more visible.

Roger Johansson has written about the differences here

One important difference, that will be a showstopper for some, is that those wonderful javascript libraries which we Rails developers have come to love and trust, won’t work without modifications, when content is actually served as XHTML.

It shouldn’t come as a surprise, but in the XHTML DOM, there is no such thing as .innerHTML – an attribute that prototype.js depends heavily on.

And a solution

Of course you can always go on serving XHTML as text/html, but it seems backwards to specify one doctype in your documents, and ask the browsers to use the render for another doctype in your HTTP-headers.

This is the reason that this site is done in HTML 4.01, but this brings me back to Ruby on Rails helper functions. All these generate valid XHTML, but sometimes that means invalid HTML. I browsed the Rails source for a while, and found a nice solution for that. In your application helper add this:

def tag(name, options = nil, open = true)
"<#{name}#{tag_options(options.stringify_keys) if options}" + (open ? ">" : " />")
end 

This overrides the tag function, and for me these 3 lines have been enough to solve all HTML 4.01 validation problems with Rails.

[Update – I’ve since changed the site from HTML to Transitional XHTML after all, in order to play around with MicroFormats a bit]