Web DevCenter
oreilly.comSafari Books Online.Conferences.
MySQL Conference and Expo April 14-17, 2008, Santa Clara, CA

Sponsored Developer Resources

Web Columns
Adobe GoLive
Essential JavaScript
Megnut

Web Topics
All Articles
Browsers
ColdFusion
CSS
Database
Flash
Graphics
HTML/XHTML/DHTML
Scripting Languages
Tools
Weblogs

Atom 1.0 Feed RSS 1.0 Feed RSS 2.0 Feed

Learning Lab






CSS Hints for Internet Explorer 5

by Peter-Paul Koch and Apple Developer Connection
11/15/2002

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:

1. Bugs having to do with position: relative: 2. Bugs creating extra margins for elements: 3. Bugs in the implementation of the overflow declaration:

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 break
line break
Again, 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.

Example:

div.container {
   position: relative;
   border: 1px solid #000000;
   top: 50px;
   left: 50px;
   width: 200px;
}

.testdiv {
   position: static;
   border: 1px solid #000000;
   background-color: #ffffff;
   padding: 10px;
   margin: 0px;
}

I explicitly set the <DIV>s inside the container to static. The correct rendering is shown below in a screenshot from Mozilla:

Correct Rendering Screen Shot

In Explorer 5 for Mac, though, you'd get the following rendering.

Incorrect Rendering Screen Shot

Mysteriously, Explorer moves all <DIV>s (except the first one) 50px to the right. They inherit their position (relative) and their left (50px) from their parent.

Workaround: None. Fortunately, there's not a great demand for this type of styling.

Pages: 1, 2, 3, 4

Next Pagearrow