Internet Explorer 5 Mac: oddities

Miscellaneous float bugs

Before anything: float and width

Mac IE5 can be pretty strict with the specifications when it comes to the float property. It does require that a width be declared on floated elements. To quote the CSS2.0 specs (emphasis mine's).

A floated box must have an explicit width (assigned via the 'width' property, or its intrinsic width in the case of replaced elements).

If no width is declared for the floated block, then the browser will expand the block to the full width of its parent (containing) block. Other browsers follow more closely the spirit of the CSS2.1 specs, which allow for “shrinkwrapping” of floated elements.

Floated image in a paragraph with a fixed width. Applies to IE5.x OS9 and OS X.

When an image is floated (left or right) in a paragraph with a declared width, ie. p {width:350px;} (any unit), IE Mac will expand the width of the following paragraph to make room for the image. This (only) happens when the first paragraph does not contain enough text to fill the space created by the image box. Simplified test case. This is not limited to images, a floated <span> does the same; test case. Workaround: don't declare a width on the paragraph itself, but wrap them in a <div> instead — sample, or use margin-right, margin-left.

Note: this also applies to a <div> tag, and other block level elements.

Paragraph escapes out a fixed width parent box adjacant to a floated box

Mysterious magnetism. A box is floated on the right side. On the left side, a <div> with fixed width. The paragraph(s) escape out of the box, as if attracted by the floated box. Replace the floated box by an absolute positioned <div>, and everything falls back in place. Testcase and screenshot.

Clear is wrongly inherited into child elements.

This page tells it better... [but only tells one part of the problem].

Further testing show that this is not limited to floated elements. Any block level element will clear a floated element when the common parent element has clear: anyvalue; applied; example. Another, weird example: a paragraph <p> is given {clear: both; width: 30em}. The first–letter is floated: p:first-letter{float: left; font-size: 300%;}. In IE 5 Mac, the rest of the paragraph appears under the first letter.

[ Updated ] A simple sample file of the above problem. The parent container has clear:both declared in the style block. The two examples on thepage show how the floating is ignored by the browser. The second block of text drops completely below the first one. By using display:inline-block for one of the two boxes, the first example (a common layout technique these days) can easily be fixed in IE Mac (the code is best hidden from other browsers, in this particular case). Notice that it doesnt fix the problem for the second example on the page, as this is not how display:inline-block works: it creates a box that rest on the baseline of a fictive line box in the second example, and the paragraph drops below the test box in IE Mac.

Float Escapes its Parent’s Content–Edge When Parent is Relatively Positioned.

This one has been submitted by Garret Smith. A floated block level element, containent in relatively positioned parent does not account for the offset specified on the parent element. In Garret's testcase, an image is floated an escapes out of the parent box {position:relative; top:20px}. In the next testcase, the floated <div> escapes both horizontally and vertically out of the parent box {position:relative; top:40px; left:40px}. In both cases the floated box is positioned where it originally would have been if the parent container had not been positioned. screenshots.

This can (possibly, depending on your design) be fixed by using {margin-left= xx} instead of {left} to offset the box. testcase Another day, another (possible) work around: setting the parent box to {display:inline-block; this is better hidden from other browsers. showcase.

Background–painting bug caused by floated elements.

In this sample, the navigation strip on top of the document is an unordered list with {display:inline}. A background-color is specified on the <li>. This list contains floated linkboxes <a>. Oddly, IE5 Mac continues to paint the subsequent elements <p> and <ul> on the page with the background color of the <li>, but only in the part of the page visible in the window. Scroll up and down, and watch the red background-color disappear. screenshot.

A default 3px margin on floated images

When images are floated (either left or right). IE Mac adds a small 3px margin around the image (something similar as happens in IE5.0 win). Sample. This can be easily defeated by explicitely resetting the margins to 0 in the stylesheet. Thanks to Adam Kuehn for the heads up. Note that this only happens when images are floated; floated spans do not suffer from this.

Floated blocks nested in a table–cell

Floating a block level element to the left in a tablecell (<td>) causes the table to expand to whatever IE5 Mac sees fit, but way beyond the width of the parent block element. This happens only when the element is a <div>. In the following samples, the width of both the <table> and the <td> has been locked down (table {width:700px}). Sample1: left–floated <div>'s; sample2: right–floated <div>'s; sample3: floated paragraphs (<p>). Both sample2 and sample3 work correctly in IE5 Mac.

There is a solution for the problem of floated div's within a table–cell. IE Mac supports the css2.1 property display:inline-block (specs). This can be used to serve IE mac a different styling, which is best hidden from all other browsers. An example is available.

Text–align property is not applied to direct children of a floated block.

Mac IE5 tends to 'forget' the text-align property when declared on floated elements. A simple example to illustrate the case. Simple wrapping the textnodes inside the <li> in a tag (wrapped in a <a>) restores the functionality of the text–align property, in this simplified testcase. It doesn’t always work however ! Countless examples of similar markup can be found on the web: a tipical example, the Opera web site; screenshot in IE mac). Other parts of the mark up influence this behaviour (and this makes it difficult to point out an exact cause). A foolproof, albeit somewhat ugly method, to work around those cases is to wrap the textnode in a <span> tag — as shown in this examplescreenshot from the test cases.

Note also that it is not limited to floated <li>. This might also happen in other cases, and is entirely dependent on the surrounding mark–up. The same fix applies.

section - contents

Also around here
[ Empty spaces ]
a weblog

This collection of documents and test cases related to Internet Explorer 5 for Mac is no longer maintained and is only kept online for historical reasons.

Comments and suggestions: are not needed anymore. Thanks to all who provided info and tips in the past.

File created: September 27, 2002, updated: September 09, 2009.

back to top

permanent location: