html5 and Firefox2

If you’re using html5 for your site, and care about what the 3% of Firefox 2 users experience, then this should help you.

For me it wasn’t so much the 3%, it was that my pages work perfectly in IE6, but are a complete mess in Firefox 2, and I just couldn’t live with that.

The WHATWG blog has two fixes to get Firefox 2 to see the new elements but neither have been fully explained – or certainly it took me some time getting a good grip on each solution.

Skip to the end of the blog post if you’re only interested in the solution I’ve got running, rather than the preamble that goes with it.

This fix also handles Camino 1.x as it uses the same render engine as Firefox 2.

Firefox 2 html5 rendering issue

Simon Pieters explains it as:

Firefox 2 (or any other Gecko-based browser with a Gecko version pre 1.9b5) has a parsing bug where it will close an unknown element when it sees the start tag of a “block” element like p, h1, div, and so forth.

JavaScript Solution?

There’s the JavaScript solution that Simon proposes – which does work, but it isn’t complete.

The solution proposed on the blog post only solves the markup in the example (it may have been implied, but it took me a while of debugging to work it out).

The other dependancy the solution has is that the elements in the tags array must be in the order that the elements appear in the DOM.

It also can’t handle nesting down in to the node – though I’m sure it can be updated to handle this.

The main problem is for the code to work properly, you need to: a) give the nodes in order, and b) somehow explicitly state how the elements will be nested.

I played around in the DOM inspector in Firefox 2 and found no original reference to the DOM.

For anyone hell bent on doing a pure JavaScript solution, there is a way, but it’s convoluted (and apologies if my solution below is even more convoluted!):

  1. Run an ajax hit on window.location – this will give you the unmodified markup
  2. Parse the result to create a nested structure of the new elements
  3. Using Simon’s code, modify it to step the parsed structure, going in order of found elements, once it completes it’s top level pass, drop down in to the next level in the DOM and clean up the next level of the tree

Working Solution

Using Bruce’s test page, I’ve put the html5 test page on my server, and if you check it out in Firefox 2, you’ll see it working, compared to the original broken version.

There’s a few tweaks you need to get this to work, but before I go in to them, there’s one error that I found that I couldn’t work out a way around without invalidating the html5:

  • You can’t use unknown html entities, for instance a … entity (which has been commented out of Bruce’s example page).
Update: after speaking on the #whatwg IRC channel, the work around is to use the XML entity, i.e. … is …. You also can look up html entities.

That bug may just be enough for me to write the JavaScript solution…we’ll see.

The Fixes

You need two things:

  1. mod_rewrite to trick Firefox 2 in to thinking the page is xhtml
  2. xmlns attribute in the html element to get the page to render


In this example, I’m only running the content-type trick through .html files only – but you can modify this rule as you feel fit (i.e. it could be that you ignore anything in your assets directory instead).

I’ve not got the Gecko 1.9pre build to run live tests, but I’ve run pattern matches and they’re good so far as I can tell.

This rule sends the xhtml content-type to all Gecko based browsers where version is less than 1.9, or “rv:1.9pre” or “rv:1.9a” or “rv:1.9bx” where x is less than 5 (source).

RewriteCond %{REQUEST_URI} \.html$
RewriteCond %{HTTP_USER_AGENT} rv:1\.(([1-8]|9pre|9a|9b[0-4])\.[0-9.]+).*Gecko
RewriteRule .* - [T=application/xhtml+xml]


Then to get the page to render the style properly, add the follow (typical html4) attribute to the html element:

<html lang="en" xmlns="">


For me there’s a bigger problem that I have to be comfortable to say that IE users must have JavaScript enabled to get the html5 enabling script to work, but I think you have to justify this on a case by case basis.

I’ve been discussing filtering processes that convert the html on the fly out the door (with server side caching), but my concern is that it means supporting two models in the CSS such as section, .section {}, and then you have the issue of IE6 not being able to handle <section class="intro"> as this would be .section.intro which we’ve all run in to that headache.

Finally there’s the JavaScript selectors that you might use. Sure you could write $('section, .section') but at what point do we draw the line?

6 Responses to “html5 and Firefox2”

  1. Why not just always serve XHTML5 content, and then fall back to text/html if they’re using IE? Here’s a WordPress plugin I developed to do this as well as rewrite the markup for IE6:

  2. Rather than check the version number, it’s easier to check the Gecko build date

    RewriteCond %{REQUEST_URI} .html$
    RewriteCond %{HTTP_USER_AGENT} Gecko/(d{10})(?!.*Opera)
    RewriteCond %1 <2008032619
    RewriteRule .* - [T=application/xhtml+xml]

    That gecko date is Firefox 3b5 which came out very shortly after the HTML5 fix landed. Anything before that date requires xhtml+xml to render HTML5. I wrote this fix before Firefox 3 came out.

  3. dear lord, kill me now… like supporting the 45%+ of broken <= IE7 wasn’t enough of a PITA … and YOU had to dredge THIS up!? (%$^@!)

    good work, nonetheless ;)

  4. Kroc, Mozilla maintain several branches of Gecko, so the build date alone doesn’t say much. The UA string for Firefox is:

    Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20081217 Firefox/
  5. @zcorpan Aha! Thanks for spotting a hole in plan! I shall have to use Remy’s code. I wonder though if there’s Gecko-based browsers though, that don’t provide the revision number… (aggregators?)

    Secondly, it should be noted that when you serve as XML to Firefox 2, there is no progressive rendering! Make sure your HTML is compact, and serve gzip ideally. Lastly, if you make even one mistake outputting a tag (and it’s not valid XML), you’ll get a yellow fail screen. Serving as XML to Firefox is not good if you know bad HTML can get into your output somehow (user comments for example).

  6. I think these issues should be solved with the new edition of Firefox coming up?

Leave a Reply
Not required

CODE: Please escape code and wrap in <pre><code>, doing so will automatically syntax highlight