Internet Explorer 5 Mac: oddities

IE 5 Mac: miscellaneous bugs

Relative positioning and inheritance of positioning offset.

As mentioned on the CodeBitch pages IE mac incorrectly inherits the positioning information left:value and top:value into the children of a relative positioning container. One often mentioned solution is to use margin:value instead of left:value and top:value. Sample1. A second work around: explicitely declare the overflow–property: overflow:auto on the offending relative positioned parent block: see sample 2. A reader mentioned that this caused problems on his win98–IE5 combo. As always test early, and this little workaround can be hidden from other browsers.

Fixed positioned box and link boxes.

Mac IE 5 does support position:fixed almost correctly but for one annoying problem: if the fixed positioned box contains links, then these cannot be detected by the pointing device. It can be illustrated as the fixed positioned box and its contents floats above the viewport, and over the pointing device. Links can be clicked, and are fully active, but :hover effects are not triggered. The same applies to javascript driven mouse over events. But :focus events work correctly.

Text–indent oddity

An inline image that is inserted following a line–break <br> in a paragraph with text-indent declared is positioned incorrectly and does not respect the text–indent: read more....

Inheritance of !important declaration with font-size.

When an !important declaration is added to a font-size declaration, IE Mac will apply the rule to all children of the box with this particular font-size rule, even though those children have another font-size declared: sample and sample 2. In the first sample, an !important delaration is added to the body tag, and to the first h1 tag. Only the rule on the h1 is applied, all other block elements take the font-size from hte body tag. In the second example, the !important rule is attached to the div tag, the p tag has a font-size declaration on it's own, but this is not applied.

It should be noted that adding a !important declaration to the font-size is very user unfriendly, as it easily can break a user style sheet

Fonts, font-family and content–encoding.

Mac IE 5.2 completely ignores font–family and font–size attributes set on the body declaration of the style sheet, and it ignores font–family, but not font–size, in any declaration.

This happens when the content encoding of the page is set via a meta tag, and the default language of the OS is different from the one specified in the meta tag and the content encoding header sent out by the server is different from the one specified in the meta tag. Example: a page with content encoding as UTF–8, set via a meta tag, (containing roman text and styling set to use some type of roman fonts), when viewed on a Japanese Mac OS 9 or Mac OS X with Japanese a system language will lose most text formatting (see my note here, or see Jay Allen's sample.

The default Western roman encoding (iso-8859-1) seems the exception here (possibly because it is the default header sent out by most servers). Work around: set up the server to send the correct content–encoding header (through .htaccess should be possible), or use server–side languages to send the correct content-encoding header [my Hiragino–font demo file use php to do this].

Mac IE also fails to recognize the character encoding of stylesheets set via @charset:utf-8 or similar. See a series of tests on the W3C website. The browser ignores the @charset declaration, and assumes the character encoding from the html document. Non ascii characters are ignored.

Problems with background images

  1. IE Mac cannot see background images that are linked to a stylesheet using the following code: selector {background: #ccc url('myimage.gif')}. Note the single quotemark in the url. More in the hiding and linking section.
  2. Positioning a non-repeated background image, attached to the <body> tag, at the bottom of the document is buggy: first of, the image is always positioned at the bottom of the viewport, instead of the bottom of the document (even if {background-attachment:scroll;} is used). Furthermore, when scrolling the document, the image will leave a trail, an ugly residue behind. demofile and screenshot. Note: This only happens when the image is positioned at the very edge of the document {background-position: bottom right} or {background-position: 100% 100%}. Possible fixes: use {background-attachment:fixed;} for IE Mac. The visual effect in this browser will be the same. Another solution is to attach the background-image to another element than <body>, as is the background image at the bottom of this document; a third solution: don't position the image at the very edge, but leave a small offset: {background-position: 99% 99%} will work.

Combination of “vertical–align” and “background: inherit”

Ian Leckie discovered that a combination of “vertical–align” (with any value) and “background: inherit” would crash IE5 running on Mac OS X (both 10.1 and 10.2) IE5.1 running on OS 9 is not affected by this. It seems that this combination, when applied to the same element in a linked, imported or embedded style sheet triggers the bug. Applying the same styles inline does not trigger the bug.

Some further testing reveals that other combinations also trigger this bug, ie using “letter–spacing” or “word–spacing”; possibly others, mostly rules that affect the flow of text within the line box. Update: {color: inherit}; also consistently crashes IE5.x Mac in combination with the above properties.

Code used in this simplified test case: div {vertical-align: top; background: inherit;}

Sample1 (new window) crashes IE5 mac. <style> embeded in the <head> of the document.
Sample2 (new window) does not crash IE5 mac. <style> applied inline.

Fix: use {background: transparent} instead of {background: inherit}.

Text re–flow in a block level element that contains links.

When a block level element (ie. a <p> or <div>) contains links (<a href="">), IE will flow the text in a very irregular way, breaking the text flow where there is no apparent reason for breaking it, sometimes halfway the line, although there is space enough to add more text on that line. An example is the second paragraph — under "Other sources for IE5 mac problems" — of the opening page of this section. You might have to resize the window to see the effect. This can be especially annoying in a thight layout. I have not managed to find any fix for this. In some cases, adding overflow:visible to the stylerules for the offending blocks (p, li,...) seems to help. Avoiding constraining the block elements through the use of width can help as well.

Additionally, James Craig had a problem with disappearing text on his blog. We discovered that, when the parent container for the bodytext is given {position: relative}, sometimes words, or parts of sentences, disappeared. A screenshot is available here. Deleting the {position: relative} fixed the problem for James. YMMV.

Note: these problems with text flow are related to other 'link' problems: see the phantom links problem here, and some related oddities on the Macedition pages.

Unexpected gap between two <div>'s.

When a block level element <div> has a {height:xx} set, IE5 mac will leave a gap between this <div> and the next one, even though both <div>'s have the adjoining margins set to 0. This happens when the contents block inside the first <div>, ie a paragraph or a header, has no setting or a setting other than 0 for {margin-bottom} specified. The bottom margin of this contents block leaks out of the container block: sample. This can be fixed by setting {margin-bottom:0} on the contents block: sample2. Another fix: don't set height on the first <div>.

Using display:table-cell to simulate min-height

Some browsers have poor or no support for the min-height property. IE (both on mac and Win) do not support it at all. While IE Windows equates height with min-height, this doesn’t work in IE Mac, as it correctly support the height property. Another way around is using display:table-cell, as documented by Vincent Garcia, as a solution for some versions of Safari (up to 1.2). This solution has some annoying side effects in IE Mac, as shown in this simple test page, which includes a screenshot of the rendering in Mac IE. The contents of the div is pushed below the box. The usual work arounds to hide styles from IE Mac apply.

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 last updated: September 09, 2009.

back to top

permanent location: