intertwingly

I’ve made some progress getting my recent slide show to display on IE.  For the moment, I’m not focusing on presentational aspects, like rounded corners and the absurdly wide gutter that IE puts between the title and content.  That will come later.

The reason why I am doing this is that I have been experimenting with presentation styles for years, and I am finally feel like I am getting closer to something that fits my style.  Ultimately, I will likely produce a stylesheet designed explicitly for a fixed 1024x768 display, and use images for rounded corners.  As well as produce a script that automates the portions I did manually.

Anyway, the point of this post is to document a few of the obstacles I have encountered, and capture what I have done so far.

Terminating Scripts

It may be XHTML (still served as text/html at the moment, even to browsers that support XHTML), but the following doesn’t work with IE:

<script src="pager.js" type="text/javascript" />

Instead, the reference to the script must be done this way:

<script src="pager.js" type="text/javascript"></script>

Dangling Arrays

Consider the following:

var data = ['foo', 'bar', 'baz', ]

With Firefox, you get three elements.  With IE, there is an additional fourth element with a value of undefined.

Replacing styles

With Firefox, you can replace the innerHTML for a <style> element, and thus affect the presentation of multiple elements on the page.  With both IE6 and IE7, this results in an “Unknown Runtime Error”.  See this demonstration.

The alternative is to update each of the individual style attributes on each element separately.

getAttribute

Finding the element with a given class value is made a bit more challenging with IE as getAttribute("class") doesn’t seem to return this value.  Apparently that the most portable approach is to iterate over all the attributes.

For those keeping track, what once was finding a single element and replacing its innerHTML has become:

var span = document.getElementsByTagName('span');
for (var j=0; j<span.length; j++) {
  for (var k=0; k<span[j].attributes.length; k++) {
    if (span[j].attributes.item(k).nodeName == 'class') {
      if (span[j].attributes.item(k).nodeValue == instructions[i]) {
        span[j].style[instructions[i+1]] = instructions[i+2];
      }
    }
  }
}

Making things go away... and come back

CSS is interpreted differently between the two browsers.  Marking something as visibility: hidden doesn’t necessarily collapse the space that the text would have taken.  To really make it go away, adding width: 1px; position: absolute; overflow: hidden gets the job done.  Making it come back, and in the right place, in both browsers, one also needs to set display: inline.

setTimeout vs XHTML

An unsolved problem to date is that the Javascript function setTimeout does not work as expected when the DOCTYPE is XHTML.  I haven’t managed to find a solution to this just yet.  A similar problem was reported here.

delays

As near as I can tell, Firefox updates the display in the background, so setTimeout is effective immediately. IE, by contrast, does’t seems to wait until the page is updated before it starts the timer. The net effect is one where IE appears to significantly underperform Firefox.