CSS Hints for Internet Explorer 5

As we know all too well, the Windows and Macintosh builds of Microsoft's Internet Explorer 5 are based on different rendering engines and therefore react differently to the same HTML or CSS. This means that Web developers have to test their pages in both browsers--they can't assume that a page that works in one will work in the other.

In general, the Mac version of Explorer is more strict in its standards compliance (and supports more of the standards) while the Windows version supports more Microsoft proprietary styles and JScript methods. And the Mac version is way ahead in terms of CSS support. For example, it supports position: fixed, something the Windows browser still hasn't been able to implement.

The Mac build of IE, like most browsers, has some bugs and idiosyncrasies that can trip up unaware developers. This article describes three types of problems you're likely to see:

These all appear in any version of Explorer 5 for the Mac, on both Mac OS 9 and OS X.

The Commented Backslash Hack

Fortunately, Web developers have a tool for dealing with these problems. A useful CSS hack allows developers to define special styles without resorting to browser detects and separate CSS files.

Here's how it works: Explorer for the Mac interprets a backslash in a CSS comment as an escape for the next character, as if it were reading a regular expression. Taking advantage of this incorrect behavior, you can escape the end-of-comment marker (*/) so Explorer won't parse certain style declarations:

element {
style: for Explorer on Mac
}
/*
This is a CSS comment where the end-of-comment marker is escaped.
The following styles are not read by Explorer
because it thinks they are still part of this comment.
\*/
element {
style: For all other browsers, it overrules the previous style
declaration.
}
/*
Another comment, now with a normal end-of-comment marker. Explorer
sees the end of this comment as the end of the previous one.
*/

So now you can define styles for Explorer and overrule them for all other browsers. This hack can solve a number of CSS-related problems.

Bugs related to position: relative

The position property takes one of four values: static, relative, absolute or fixed. The first (static) is the default value, the last (fixed) is still not supported in Explorer for Windows. Developers frequently use position: absolute while tending to avoid position: relative.

When giving an element a relative position, the element is initially placed in the natural flow of the page and then moved to its new position (as defined by the top and left properties). For example, I styled this paragraph with a top and left of 10px, so it's slightly askew.

This effect is rarely useful. What is useful is that a relatively positioned element becomes a container for elements with position: absolute. If an element has these styles:

element {
position: absolute;
top: 10px;
left: 100px;
}

...it would normally be positioned at coordinates 100,10 from the upper left corner of the browser
window. But if an ancestor of this element has any position but static, the element is positioned relative to this ancestor.

So you can use an element with position: relative as a container for absolutely positioned elements.

line breakline breakAgain, I've positioned this paragraph relatively. I've also absolutely positioned an em element (containing the text "This is the em") with coordinates of 100,10. These coordinates use the upper left corner of this paragraph as their reference point, not the upper left corner of the browser window, so the em is still within this paragraph.
This is the em.

position: relative is occasionally used for such effects, but it also has some ugly side effects in Explorer, as you'll see below.

Incorrect inheritance of position: relative

Bug: Elements inside a relatively positioned element can incorrectly inherit their
position value and their left or right properties (though not their top or bottom properties) from their parent.