This Much I Know » Tim Down

Empty XHTML tags and Internet Explorer DOM traversal

Tim Down — Thu, 15 Oct 2009 15:11:59 +0000

Here’s the problem: HTML and XHTML pages containing empty elements with no end tag such as break JavaScript DOM traversal methods in Internet Explorer 6, 7 and 8, resulting in nodes after such an element showing up in more than one node’s childNodes collection.

Consider the following XHTML document:





    Test
    


Paragraph containing some text followed by an empty span
Second paragraph just containing text

The idea is that when the page loads, the JavaScript will get a reference to the empty span and display its HTML contents. That will be an empty string, right? Not in IE it won’t. In IE, you get the following:



Second paragraph just containing text

Now, while may be valid in documents with an XHTML Strict doctype, this makes not a jot of difference to IE, which always parses XHTML as HTML, regardless of doctype. What seems to happen is that IE finds the offending span tag (henceforth known as ‘Bad Span’) and ignores the closing slash. Whether it does this because it knows that such a tag is invalid in HTML or because it always ignores closing slashes I’m not sure. Whatever, the result is that IE scans for a corresponding and since none is forthcoming, skips over the

(which it presumably also considers invalid without a matching

inside the span) and carries on to the end of the document, adding subsequent nodes to the ’s childNodes collection as it goes.

This is not good news. Consider the second

element. IE somewhat contrarily knows enough about the proper structure of the document to place it in the childNodes collection of the body element, but as shown above, it also shows up in the Bad Span’s childNodes, meaning a node can effectively have multiple parents. The DOM is no longer a hierarchy but a map. You may be curious to know which of its parents the second paragraph considers its real parent. The answer (from its parentNode property) is Bad Span.

Now, an unsuspecting piece of JavaScript could easily get into problems. Imagine you had a script that acted on every span in the page. Let’s say for the sake of an example you wanted to set every span’s contents to just be the text “[SPAN]“. You might do something like the following:

function changeSpans(node) {
    if (node.nodeType == 1 && node.nodeName == "SPAN") {
        node.innerHTML = "[SPAN]";
    } else {
        // Traverse the node's children to find more links
        for (var i = 0; i < node.childNodes.length; i++) {
            changeSpans(node.childNodes[i]);
        }
    }
}

changeSpans(document.body);

Run this in every other browser and you get what you expect, but run this in IE and your second paragraph (in fact, anything after Bad Span) gets wiped out. This is a contrived example, but real life scripts recursively traversing and acting on the DOM could easily fall foul of this problem in IE. At best, you could end up traversing some nodes multiple times, which could be significant if your code is not expecting it.

It’s not easy to work around, either. I have found no simple way to detect empty elements like Bad Span, since the closing slash is not present in the the span’s parent element’s innerHTML property or its own outerHTML property. The only strategies I can see are:

Traverse the document from start to finish, keeping a collection of the first parent node you see for each node and ignoring any node whose childNodes collection contains a node you’ve already seen a different parent for, or:
Icky regular expression-based nastiness to check if each node could possibly have the children it claims to have based on its parent’s innerHTML.

Neither is very appealing. Suggestions welcome.

Range.intersectsNode, Mozilla and WebKit

Tim Down — Tue, 14 Oct 2008 11:43:57 +0000

Today I needed to know whether a Range object (obtained from a selection) intersected with a particular node within an HTML document, which is a relatively common scenario when developing WYSWIYG editors. Mozilla’s implementation of Range used to have a proprietary intersectsNode method, which was ideal. However, they’ve removed this in Gecko 1.9 (and therefore Firefox 3) and provided an example function that does the same job. Unfortunately this function doesn’t work in WebKit (and hence Safari and Chrome) because of a bug in WebKit: they seem to have managed to invert the behaviour of compareBoundaryPoints with END_TO_START and START_TO_END. Tsk. So I’ve modified the Mozilla example to work consistently with all browsers that support Range:

function rangeIntersectsNode(range, node) {
    var nodeRange = node.ownerDocument.createRange();
    try {
        nodeRange.selectNode(node);
    } catch (e) {
        nodeRange.selectNodeContents(node);
    }

    var rangeStartRange = range.cloneRange();
    rangeStartRange.collapse(true);

    var rangeEndRange = range.cloneRange();
    rangeEndRange.collapse(false);

    var nodeStartRange = nodeRange.cloneRange();
    nodeStartRange.collapse(true);

    var nodeEndRange = nodeRange.cloneRange();
    nodeEndRange.collapse(false);

    return rangeStartRange.compareBoundaryPoints(
             Range.START_TO_START, nodeEndRange) == -1 &&
           rangeEndRange.compareBoundaryPoints(
             Range.START_TO_START, nodeStartRange) == 1;
}

Note: WebKit does implement the intersectsNode method on Range. However, I prefer not to use it in the above function because it’s not specified in the DOM standard for Range and may therefore end up being removed from WebKit, and there’s more chance of the function behaving consistently between browsers if it uses the same code in each.

JavaScript eval in iframes

Tim Down — Mon, 22 Jan 2007 14:50:14 +0000

In the course of developing a new version of log4javascript, I was adding a command line feature that required the ability to evaluate and execute code in an iframe from within the main window. Fine, I thought, I’ll just call eval on the iframe window object. Which predictably worked fine in Firefox and Opera 8+, but did nothing in IE, which seemed to be missing the eval method on the iframe.

After some googling I came across a mention of the IE-specific execScript method of window objects, which looked like it might do the job. However, I got my implementation slightly wrong but then noticed that after the first (wrong) call to execScript my original code was working! It turns out that calling execScript once on a window object causes the eval method magically to appear. This is true of every version of IE I’ve tested in Windows (7, 6, 5.5, 5, even 4); I haven’t tried IE on the Mac, or Safari, yet.

So I have a nice easy workaround in IE that still works in other browsers:

function evalIframe(iframe, command) { if (!iframe.eval && iframe.execScript) { iframe.execScript("null"); } iframe.eval(command); }