Opinion: Is the Firefox development model really better than Microsoft’s?

Everyone loves bashing Microsoft and preaching the vast superiority of Firefox over IE, particularly its near-perfect implementation of W3C standards. Unfortunately, that might be true as long as you’re doing what the most vocal advocates (the CSS folks) are doing, if you happen to rely on some other “supported” standard, you might find yourself in deep ****.

As my regular readers know, I happened to make a decision to use client-side XSLT a while ago. From the technology standpoint, it was a perfect solution … until Firefox 3 came out. It has so many XSLT-related problems that it’s almost impossible to get the right combination of relevant parameters to have the same XSLT stylesheet working on Firefox, IE, Chrome and the web server (for non-XSLT-capable clients).

OK, one would understand that every major software project has bugs. But it’s hard to understand that so many of the XSLT bugs are untouched after several years. For example: generic ticket describing XSLT result document problems (4 years), HTML-DOM initialization issues (5 years), Firefox crashing when combining XSLT with document.write (6 years), Firebug not working on XSLT-generated pages (1,5 year).

I’ve heard all about limited resources and priorities in my “previous life”, but let’s face the reality: once the motivation (let’s beat IE) wears off and the platform accumulates years of old sins and bad decisions, the development model doesn’t matter. Firefox is becoming no better than IE.

Firefox XSLT errors

When I decided to use server-side XML output and client-side XSLT transformations a while ago, Firefox 2 was the ideal development platform – reliable, well implemented browser with excellent debugging capabilities (Firebug). Since then, the XSLT ignorami contributing code to Firefox have managed to break so many things I simply have to document everything I know to be broken in one place:

• You have to use <xsl:output method=’html’>, and the root element of the transformed XML tree must be html (not HTML), otherwise the DOM is not properly initialized. DOCTYPE does not matter.
• Even though the DOCTYPE parameters in the xsl:output indicate transitional HTML, the attributes are case-sensitive (for example, onClick does not work).
• DOM initialization on Unix differs from Windows (document.body is missing).
• In some versions, numerous properties of the document object are missing.
• Output escaping cannot be disabled (this is not a bug, but a very particular feature implementation).

On top of everything else, Firebug does not work.

It breaks my heart, but I have to admit that with the rollout of Firefox 3 Internet Explorer 7 does a better job of handling client-side XSLT than Firefox.

Blogger backup works (finally)

I have no problem bashing Google (or anyone else that can't get their act together), but then it's also fair to report when they get something right. They've managed to fix the Blogger backup in the last month or so; now I can successfully back up my large blogs (900 posts, thousands of comments, 6 MB XML file). Great job :)

Firebug does not work on XSLT-translated pages

If you want to use Firebug with Firefox 3 on pages using client-side XSLT transformation, you’re out of luck. Firebug simply does not work; the only way to a half-working environment is the following:

• Restart the browser
• Open an XML page with the xml-stylesheet directive.
• Open a new tab and load a regular page into it.
• Switch back to the previous tab. Firebug works within the context of the currently loaded page.

What’s really sad is that this has been reported by one of the Firebug developers almost two years ago … and nobody found it important enough to change the bug status from NEW to anything else.