IE8 has a right table border problem on JavaScript-inserted cells

If you use collapsed table borders on with IE8 and insert or delete cells in the table with JavaScript, the right border will be missing. For example, when you insert a row in a table this CSS ...

.fmtTable { border-collapse: collapse; width: 100%; border: 1px solid #D0BFAB; }

... with the following jQuery code ...

$("<tr><td colspan='2'>Test</td></tr").insertBefore("table.fmtTable tr:last");

... the right border will disapper.

Fix: declare an extra class last ...

table.fmtTable .last { border-right: 1px solid #D0BFAB; }

... and apply it to every last cell in the table:

$("table.fmtTable tr").find("td:last").addClass("last");

Another XSLT-related bug in IE

I’ve created an RSS feed that points to various web pages that use client-side XSLT (read this article if you’re not familiar with the architecture of my web sites). The feed is accessible through FeedBurner which modifies the feed slightly to track clicks:

• All the links in the feed are modified to point to FeedBurner URLs
• The FeedBurner URLs encode the actual click destination (this allows FeedBurner to count the clicks)
• FeedBurner uses “301 Moved Permanently” status code to redirect the user to the target web page.

When the target web page is an XML document with xml-stylesheet directive, Firefox and Chrome display it correctly, but IE 8 crashes, as it interprets the XSLT stylesheet address relative to the “old” location (FeedBurner), not the redirected location.

I could fix this problem by hard-coding absolute XSLT URL in the XML document, but then some browser might consider that a potential CSS attack, causing further problems. For the moment, IE 8 has proven to be closer to Firefox and its XSLT woes that I thought.

A nasty Firebug “surprise”

If you happen to believe that the client-side XSLT transformations are a good thing (I am firmly footed in that camp), Firefox 3.x brings nothing but disappointments. Now it's Firebug's turn: they’ve managed to mangle the console.log function. It worked a while ago, but then a brilliant mind decided to re-implement it with a hidden DIV between the HEAD and the BODY element:

<div id="_firebugConsole" style="display: none;" FirebugVersion="1.4.5"/>

This DIV is created automatically for regular (X)HTML pages, but not for XSLT-generated content, so the output of console.log gets sent to /dev/null (plus you get loads of weird error messages).

Firefox 3.5 XHTML support stinks

Continuing my Firefox “quality” rants: I just found the willpower to completely redesign my AJAX framework, going from IFRAMEs to jQuery AJAX calls (replacing straightforward and quite elegant XSL transformations with pages of convoluted JavaScript code) to work around the bugs in FF3.0, only to find out that FF3.5 is even worse and introduced numerous additional “features”.

For example, FF3.5 requires an explicit </script> tag within an XHTML document with proper DOCTYPE. The following document was validated with W3C XHTML validator …

<!DOCTYPE html 
  PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <title>Test</title>
  <script src="… source URL … " type="text/javascript" />
</head>
<body id="body">
</body>
</html>

… but it does not load the script in FF3.5.

Before anyone starts telling me that it’s not so hard to include the closing </script> tag in your source – try telling that to the database with native XML support where I’m storing snippets of the code. I had to convert the field from XML to TEXT (and lose all XML goodies I might eventually get) just to avoid the elimination of the explicit closing tag.

May I make a quick suggestion to the FF developers: maybe, just maybe, you might want to consider supporting existing web applications in parallel with adding new features that not too many people can use (because no other browser supports them yet).

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.

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.

The inconsistent consistencies are driving me crazy

Here’s a simple question: what’s wrong with this code?

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns:xf="http://www.example.com/common/xslforms">
...
<input type="button" value="X" id="tb_0" onClick="callX(0)" />

Among other things, this is not valid XHTML (as claimed in DOCTYPE) because the onClick attribute should be spelled in all-lowercase (onclick).

Now the trick question: why am I so annoyed by this code? Because it works in IE7, FF2 and FF3 if the server serves HTML to the client and fails only in FF3 if the client performs XSLT transformation using a stylesheet similar to this one:

<?xml version="1.0" encoding="utf-8" ?>
<xsl:stylesheet
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output method="html" encoding="utf-8"
  doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN" doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"/>

<xsl:template match="/">
  <html xmlns:xf="http://www.plezanje.net/common/xslforms">
…
  <input type="button" value="X" id="tb_0" onClick="callX(0)" />
…
</xsl:template>

The ever-more-crazy implementation of XSLT in Firefox will persuade me to:

• Stop using client-side XSLT transformations or
• Stop supporting Firefox and recommend everyone to use IE or Chrome.

Firefox forgets to create document.body object on Linux

If you use client-side XSLT transformations driven by xml-stylesheet pseudo-instruction in XML documents, you might encounter interesting problems when using Firefox 2 on Linux. When the  HTML page is created with XSLT transformation, Firefox does not create the document.body object, causing JavaScript libraries (for example, jQuery) to break.

Workaround: add an ID to your body tag (for example, <body id="body">) and fix the document.body object after the DOM is ready. To do it in jQuery, use the following code:

$(function() {   if (!document.body) document.body = $('#body').get(0); }

Chrome: first impressions

I've just downloaded Chrome (the new browser from Google), tested it on my applications and got immediately impressed - they all worked, even the client-side XSLT transformation driven by the xsl-stylesheet directive. Then I did a few more random tests and my enthusiasm was drastically reduced:

• The inter-line spacing on table heading texts was way too large: <th valign='bottom'>Line 1<br />Line 2</th> produced a blank line between the two text lines. I did not investigate what the root cause might be as all the other major browsers render it almost identically, so I don't really care what upset Chrome.
• The top line of our corporate Wiki (the Login text) is misplaced.
• The View source window does not display processing instructions in XML documents.
• And the worst offender: Blogger in draft works way better, faster and more reliable in Firefox or Internet Explorer than in Chrome.

Summary: I will have Chrome installed to test my applications (some visitors are already using it), but will not use it in the near future.

Constants of the DOM Node object are not implemented in Internet Explorer

The DOM Node object defines a set of constants that can be used to identify the node type. These constants are available in Firefox (and, I would assume, all other Gecko-based browsers), but not in the Internet Explorer. The expression ...

if (node.nodeType == node.TEXT_NODE) { ... }

... which would be largely self-documenting thus has to be written as ...

if (node.nodeType == 3) { ... }

... unless you define the same constants in your JavaScript.