We came across the following Cross Browser JavaScript problem whilst writing a bespoke show/hide function for some client FAQs.

The problem was that we were referencing the 'nextSibling' of an element in our JS using the onClick event. In IE this worked great, however in Firefox the 'nextSibling' could be a line break.

Example:

 <div id=”el1”><img src="imageName.gif" onClick="getNextSibling();" /></div>
 <div id=”el2”>Some text</div>

If the function getNextSibling equates to:  var element2 = document.getElementById(“el1”).nextSibling;
 
In the above, clicking on the image would return the nextSibling as "el2" in IE but "\n" in Firefox.

Breaking down the second line of HTML above as JavaScript would see it, it would look something like this:

"\n " (line break)
with element2.nodeName = “#text”;
element2.nodeType = 3; (that’s TEXT_NODE)
and element2.nodeValue = “\n”; (that’s a line break)

So after a bit of research we found that, if we test for 'nodeType' , and ensure that the nodeType is not equal to 1, then the nextSibling is the element we are after.

var element2 = document.getElementById(“el1”).nextSibling;
while (element2.nodeType !=1)
{
          element2 = element2.nextSibling;
}

And just to make sure...

alert(element2.nodeType);

Job done!

We all remember good old “clearfix” (www.webtoolkit.info/css-clearfix.html) that we use to clear floats.

This is a new “lighter” version, based on the same principle.

The major difference from the original clearfix is that we use blank content (“”) in “:after”, instead of “.” in the original one. That helps us to get rid of three extra lines of code, which purpose was to hide this dot:

and to get rid of one more IE6 specific selector used for the same reason.

If you not too concerned about validity of your CSS you could leave the code as it is, else you can put .clearfix {//display:inline-block;} (the IE specific declaration) into separate IE Only CSS, or use the same trick, as per original clearfix – redefine “inline-block” to simply “block” for not IE, using:

after IE’s “inline-block”.

Creating an overlay div isn’t a problem for modern browsers. We can do that easily by specifying the CSS property height: 100%; position: fixed;.

However, position:fixed doesn’t work in IE6, so for IE6 only we have to put position: absolute; height:100%;. This will have no effect until you put height:100%; on a parent element (usually the body tag). That brings us to a strange result, our overlay div covers 100% of a screen, but if the page is scrollable, the rest of the area isn’t covered by overlay div.

The easiest solution is to put fixed height on our div, that equals to the height of the page’s content. So, in IE6 only CSS we have the following: height:expression(document.body.clientHeight + "px");

Overlay divs can be used to blend the background whilst using a modal window.

As per an overlay div, position fixed doesn't work in IE6, so we can’t position our popup-div in a specific place on the page, even if we scroll the content.

What can help us – is recalculating the position every time we scroll the page. So, IE6 only CSS property will be: position: absolute; top: expression(eval(document.documentElement.scrollTop) + "px");

We can add some more offset, let’s say 200 pixels. top: expression(eval(document.documentElement.scrollTop) + 200 + "px");

The only problem we have now is that this popup-div doesn’t scroll smoothly enough. To prevent that we need to fix the background of the body. background-attachment: fixed;. That only works if you have an image as the page’s background.

If you don’t wan’t to fix your page’s background, you can always put a blank.gif as a background for body, and wrap the rest of your page in a wrapper height:100%; width: 100% and define it’s background as it was before on a body tag.

We had a problem where a website looked great on Windows and Mac – all browsers, but on Linux there were several issues. On analysis, these were caused by the differing font styles used by Linux. So we came up with the ultimate work around.

Before the fix we had the following CSS:

Body { font-family: Arial, Helvetica, Sans-Serif; }

Arial is not installed in Linux so the closest font (tested on Ubuntu and Kubuntu) is Freesans.

We then changed the CSS to:

Body { Font-family: Arial, Freesans, Sans-Serif; }

As a browser will pick-up the next font to see if it is installed or not. In this instance that will be Freesans, which is installed. If any operating systems don’t have Freesans installed, the next font of the font-family will be Sans-Serif, which doesn’t look too bad.

What about Windows and Mac OS? In case Arial is not installed (what is very unlikely to happen) it will simply skip Freesans (Windows and Mac OS don’t have Freesans installed) and use Sans-Serif as a font to render the page.

That’s how crossbrowser and crossOS compatibility works.

Tested on Kubuntu (version 8.04) on Konqueror and Firefox 3, Ubuntu (version 7.04) on Firefox 2, Safari 1.3 and Firefox 2 in Mac OS X (10.3), IE 6, IE7 and all other windows browsers as usual.

Looks good.