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.

OMG, more browsers are coming

The EU commission has reached an interesting agreement with Microsoft: Microsoft will present European users with a choice screen allowing them to select one of many browsers as their default browser. In principle, this is a great idea, if they could decide to offer users three or four browsers; very probably the users will have 10+ choices.

While this is supposedly good for users (and excellent for niche browser vendors), increased market share of currently irrelevant browsers might spell trouble for web developers using non-mainstream technologies (my favorite example: client-side XSLT transformation). For example, the percentage of users not using Firefox, IE or Chrome (yes, in that order) on one of my web sites is well below 5%, so I don’t care too much whether every little details works as it should. The situation would change drastically if they “minor” browsers would represent 20% of my users.

JS-Kit crashes a Blogger blog in Internet Explorer

Several times I’ve stumbled across Blogger-hosted blog that simply refused to open in Internet Explorer with the “Operation aborted” pop-up window and subsequent error page. I never tried to investigate what was going on (I simply copied the URL into another browser), but when I’ve installed JS-Kit on my blog, I’ve started getting the same problems … obviously a cause for a major alarm.

The Infinities Loop site provided an answer in the comments: a SCRIPT performing specific manipulations should be a child of BODY, not another HTML element. When I’ve moved the JS-Kit script (<script src='http://js-kit.com/extra/blogger/comments.js' type='text/javascript'/>) from the Blogger widget to the end of the page, the new fanciful JS-Kit-based comments worked flawlessly.

How crazy can it get: IE does not set the Referer field if the page was built via client-side XSLT

Some of my web sites rely on client-side XSLT transformations, triggered with the <?xml-stylesheet > processing instruction in the XML document sent by the server. A long time ago I've noticed that some of the utility functions perform differently in IE than in Firefox and finally decided to figure out what's going on. The results are "fascinating": when you click on a link in a page generated with client-side XSLT transformation, IE does not set the Referer: field in the HTTP request. I can only congratulate the coders ... you have an amazing mindset ... not to mention the QA department.

IE7, xsl:import and jQuery Transform plugin

After exhausting all other (more convenient from my perspective) approaches, I’ve had to admit that there’s only a single solution that allows you to include/import XSL stylesheets with the jQuery Transform plugin if you want to:

• Use XSL documents from another directory on the Web server.
• Use xsl:import or xsl:include in the XSL documents.
• Have a reliable cross-browser implementation.

The solution, as you might have guessed, is to use the URL pointing to the XSL document in the call to $.transform (the xsl parameter). And just in case you’re wondering why I had to try everything else: I wanted to use the $.transform() call to get the transformed HTML without the delay incurred by setting the async parameter to false.

Xsl:import fails when using XSL object in $.transform

After the initial set of xsl:import related problems I’ve encountered running jQuery Transform plugin in IE7, I’ve tried to pass the XML document as string (using the xmlstr parameter) and XSL as parsed object (using the xslobj parameter) returned by the $.get call. Works perfectly in FF, fails miserably in IE7. The error message indicates that the imports requested with xsl:import don’t work at all. Back to the drawing board …

Import/include problems in jQuery Transform plugin

I started testing the jQuery Transform plugin with a set of pretty convoluted XSLT documents that I use on the target web site, which relies almost exclusively on browser-side XSLT transformations. All server responses are initially encoded as XML and transformed on the server only if the browser does not support XSLT (or if a spider has come to visit us). Not surprisingly, the XSLTs are heavily loaded with xsl:import and xsl:include statements.

Initially, I tried to control as much as possible: read XML and XSLT into strings and perform the transformation when everything has been collected. This approach fails miserably in IE7. The reason is simple: if I pass XSLT source or parsed XSLT object to the $.transform routine, the routine tries to fix xsl:import and xsl:include references using the current web page’s URL as the base reference, which is wrong if the stylesheet has been loaded from another directory.

Conclusion: if you read XSL documents from another directory and pass them as string to the $.transform routine, make sure you use absolute references in import/include statements.

Multiple style attributes in IE and FF

I've just stumbled across an interesting discovery today: if you use the style attribute multiple times in a single HTML tag (which you should not do, BTW, but it could happen if you write HTML code by hand), Internet Explorer will merge the style definitions whereas Firefox will ignore the second style attribute.

Back to the future?

In his blog post, Steve Souders describes how IE8 increases the page download performance by using more than two parallel HTTP sessions, briefly mentioning that this violates the recommendation from RFC 2616, which was, after all, written in 1999.

Some web developers might be too young to remember why RFC 2616 has the "two parallel sessions" recommendations. It was (among other reasons) a result of the disasters an earlier version of Internet Explorer (IE3?) caused on the Web infrastructure when Microsoft in its infinite wisdom decided to open multiple parallel HTTP sessions. The browsers quickly overloaded WAN links, caused server overloads (if you use 6 parallel sessions instead of two, all of a sudden the number of "visitors" increases three-fold), firewall failures (some firewalls had licenses limiting the number of parallel sessions) and potentially NAT failures (if you have to do port-address-translation, you might run out of port numbers).

But it looks like the history needs to repeat itself ... or maybe this time the infrastructure is ready for the additional load? My "what could fail" bet would be on the servers, but we'll see in a few months ...

Reliability of client-side XSLT transformations

I've received an interesting question on my “Search Engine Optimization in XML+XSLT designs” post:

Are there considerable browser-specific differences in xsl transformation, or am I being overly cautious?

I've been using browser-side XSLT processing for three years. Although I had initial share of problems with IE5 and some releases of IE6 (finally forcing me to perform server-side transformations for IE5), IE6/7 and Firefox behave almost identically as long as your XSLT is valid. Firefox is a bit more relaxed in error handling, so it might survive an invalid stylesheet and ignore the error. Handling XML/XSLT errors on IE is a nightmare: if the XSLT transformation fails, it's almost impossible to reload the document without closing the browser (obviously IE has some serious caching problems with XML documents). To test new XSLT transformations, I usually force server-side transformations and receive good error messages from server's MSXML.

Opera is a different story. It didn't support XSLT until pretty recently and even then the document() function was broken. I have simply decided not to offer XML data to Opera visitors (they are a minority anyway) and Safari is not widespread enough in my customer base to notice.

This post is part of You've asked for it series of articles.

Microsoft's XMLHttpRequest Objects

If you don't want to use a wrapper library like Sarissa and plan to work out the differences between Microsoft's and other vendors' implementation of XMLHttpRequest, you'll find a lot of details in this post by Jonathan Snook.

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.

Which XML encoding should I use?

The short answer is utf-8. The long answer goes along these lines:

• utf-8 is the default XML encoding specified by the XML standard. If you use it, you don't have to define the encoding manually, thus reducing the chances of introducing errors. For example, some browsers get confused if the encoding specified in the xml pseudo-instruction is not the same as the one specified in the HTTP header.
• All XML parsers are required to recognize utf-8 encoding. By using it, you don't risk any future compatibility issues. For example, some of my applications break on some installations of Internet Explorer on Vista as they use windows-1250 encoding. They work fine within IE on Windows XP, Firefox on Vista (and sometimes even with IE on Vista).
• By using utf-8 you'll never encounter a character you cannot encode.

This post is part of You've asked for it series of articles.

Another IE bug: transformed plain text displayed as HTML

If you use browser-side XSLT transformation triggered with xsl-stylesheet pseudo instruction in the source XML document and set the output format to plain text with xsl:output method='text', you'd expect the results to be displayed as unformatted text in the browser window (similarly to what browser does when served a document with content-type: text/plain). Not surprisingly, Firefox behaves as expected, but Internet Explorer 7 renders the results as pure HTML (going as far as interpreting the start-of-tag characters).For example, when the following XML document ...

<?xml version="1.0" ?>
<?xml-stylesheet href="t1.xsl" type="text/xsl"?>
<data>
  <row>Sample</row>
</data>

... is transformed with this stylesheet ...

<?xml version="1.0" ?>
<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 
<xsl:output method="text" />

<xsl:template match="row">
&lt;b&gt;<xsl:value-of select="text()" />&lt;/b&gt;
</xsl:template>

</xsl:stylesheet>

... Firefox displays the resulting text (<b>Sample</b>), but Internet Explorer displays Sample.

Using transformNode in IE7

Apparently a lot of people land on my blog when using Google to figure out how to use transformNode function in IE7. The answer is simple - you don't do it, as it's IE-only function that will obviously not work in any other browser.

What you should do instead is to use a wrapper library like Sarissa that gives you XSLTProcessor object in both Firefox and Internet Explorer environments. The XSLTProcessor API is described in Mozilla documentation (which also includes a simple example).

MSXML is still only DOM-1 compliant

If you use DOM calls to manipulate XML documents returned with XMLHttpRequest object (and who doesn't), you'll be sooner or later highly upset when the code you've tested on Firefox or Opera fails in IE (including IE7). The reason - Microsoft still did not implement Node.getElementById function. So here's the "replacement":

function getDomById(e,id) {
  if (e.getElementById) { return e.getElementById(id); }
  if (e.documentElement) e = e.documentElement;
  
  var cn = e.childNodes;
  for (var i = 0 ; i != cn.length; i++) {
    var n = cn[i]; 
    if (n.nodeType == 1) {
      if (n.getAttribute("id") == id) return n ;
    }
  }
  for (var i = 0 ; i != cn.length; i++) {
    var n = cn[i]; 
    if (n.nodeType == 1) {
      var result = getDomById(n,id); if (result) return result;
    }
  }
  return false;
}

Note: The procedure is doing breadth-first search as I was looking for IDs that were pretty high in the hierarchy of trees with many branches.

IE7 bug: addEventListener does not work with table row mouseover event

If you want to implement your JavaScript code using DOM-compliant events, you'd be unpleasantly surprised to learn that table rows in Internet Explorer do not respond to mouseover events attached to them with addEventListener. Firefox and Opera work as expected. The only way to achieve cross-browser compatibility is to use the old onmouseover properties: tablerow.onmouseover = myfunc; instead of tablerow.addEventListener("mouseover",myfunc).

IE7 breaks some AJAX libraries

Probably this is very old news (and Internet is full of related blog entries), but somehow I've managed to miss it ... If you use XMLHTTP Request object and initialize it similar to this:

if (IE) {
  x = new ActiveXObject("Microsoft.XMLHTTP")
} else  {
  x = new XMLHttpRequest();
}

... Internet Explorer 7 will constantly complain about the page trying to use ActiveX controls (at least IE6 was silent unless you've disabled ActiveX in which case AJAX broke anyway). The proper way to deal with this particular quirk of IE is to test for window.XMLHttpRequest first (instead of relying on browser type) and use ActiveX only if needed.

Note: If you use Sarissa (which broke my AJAX application), download the latest version, it contains all relevant IE7 fixes.