CSS Bugs in IE5.x Mac

Bug list

• Problems with absolute positioning and horizontal scrollbars
• Float bug: too-wide block elements alongside floats
• Float bug: non-floated elements not wrapping correctly around floats
• Float/clear bug: Clear incorrectly inherited even when child element has clear:none specified
• Float bug: floated inline elements cause later fixed-width block elements to expand
• Float bug: incorrect inheritance of inline list item background color to subsequent elements if the list items contain floated links
• Crashing bug: vertical-align and background: inherit 
  
• Incorrect inheritance of positioning information to children of relatively positioned elements
• Final block element inside absolutely positioned element has margins outside its parent
• Intermittent double linespacing on raw text inside relatively positioned blocks
  
• Problems with text-indent, line breaks and images
• Phantom Links in Floated DIVs
• Link cursor properties not honored when inside a parent element with fixed positioning
• Backslash in comment kills next style rule
• Problems with overflow
  
• Default border width not honored on tables and table cells
• Centering tables requires long-form margin styles
• Whitespace parsing substring bug
  
• Small caps text word-spaced when it should be letter-spaced
• Form element ordering determines background coloring (IE 5.1 OSX only)
• The Huge Text Modulus Bug
  

Problems with absolute positioning and horizontal scrollbars

There’s no denying that IE5.x/Mac has all sorts of problems with positioning, resulting in horizontal scrollbars that other browsers do not need. A full diagnosis of the problem does not yet exist. The problem seems to be that in some circumstances, absolutely positioned block elements have an incorrect width, even if that width has been explicitly specified in the stylesheet. Blocks without a specified width (which should mean the default value of auto and the spec’s box width rules apply) also end up being too wide if they contain other block elements like P, or if its inline content is wide enough to go to the edge of the viewport. The problem does not arise if either the BODY or HTML elements have enough padding or margin to offset the excess width of the absolutely positioned element. This is not much help if the desired design involves a full bleed of elements or color to the edge of the viewport.

A second aspect of IE5.x/Mac’s problems with absolute positioning appears to be related to the implementation of the right property. As shown in the simple set of positioned DIVs on this page, IE5.x/Mac does not properly interpret the positioning of an absolutely positioned DIV with both left and right specified, but no width specified (or if width is explicitly set to its default value, auto). Another example of this problem is shown in a test page at DZR Design. One workaround to this problem is to use margin properties instead of left and right. IE5.x/Mac also creates horizontal scrollbars if absolutely positioned, fixed-width DIVs are positioned flush against the right edge of the screen.

Many of these problems can be solved using the fix recently discovered by Peter-Paul Koch.

Float bug: too-wide block elements alongside floats

As demonstrated in this simple test page, if there is any space alongside a float, the following block will be placed alongside it even if there is not space for a block of its specified width. This problem occurs if the following (non-floated) block element has a specified width. This bug was first reported by “Big John”. Phillipe Wittenbergh also has a test case at his site where the containing block is a fixed-width div rather than the canvas.

Float bug: non-floated elements not wrapping correctly around floats

Related to the previous bug, non-floated divs alongside floats do not have backgrounds and borders that pass under the float, as is required by the spec. Philippe Wittenberg provides test cases and further explanation.

Float/clear bug: Clear incorrectly inherited even when child element has clear:none specified

Garrett Smith discovered that clear is inappropriately inherited into floated elements when the parent (block) element has a {clear:value} style (any value: both, left or right), even when the float element is specified to have a style clear:none.The CSS2 spec clearly states that clear should not be inherited.See this test page for an example. Thanks are due to Philippe Wittenbergh for nailing down the many variations of this bug, including cases with form elements.

Float bug: floated inline elements cause later fixed-width block elements to expand

As demonstrated by Philippe Wittenbergh, if floated inline elements (images and spans) protrude down into fixed-width block elements that come after their parent block element, the width of the float is added to the fixed width of the subsequent block. It seems that IE/Mac is trying to ensure that the text content of the subsequent block element has the required width, instead of the content area defined in the CSS spec’s box model.

Float bug: incorrect inheritance of inline list item background color to subsequent elements if the list items contain floated links

The test page linked here demonstrates a strange background painting bug in IE5/Mac. The navigation bar above is an unordered list with list-style:none, with list items displayed as inline items. Inside each list item is a link (a element) that is floated left. The list items are defined to have a red background, while the links above them are defined to have blue backgrounds.

The problem in IE5/Mac is that, if the a elements are floated, the red background on the li elements carries through onto the text areas (but not the padding areas) of following elements, even if they have their own background color defined. Defining the navigation ul element as position:relative additionally results in all the text in the subsequent elements being obscured by the red background. This is clearly a background-repainting bug, much like the negative margin bug in Windows IE6, because it doesn’t apply to elements that are not in the viewport when the page is initially rendered and thus that you have to scroll down to see.

Crashing bug: vertical-align and background: inherit 

Ian Leckie and Philippe Wittenbergh 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). 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. Another workaround is to use background: transparent instead of  background: inherit. A simple example of this bug can be found at Philippe’s site.

Incorrect inheritance of positioning information to children of relatively positioned elements

Some block elements inside relatively positioned elements incorrectly inherit their parent’s positioning information. An example of this bug is shown in this page. In each case, the second and subsequent block elements (eg headings and paragraphs) are shifted to the left by the distance specified in the (relatively positioned) parent element’s left property. Sometimes, this can force the child element outside the width of the parent element, which should not happen to a statically positioned child element with non-negative margins. Defining these elements in the stylesheet to have position:static; does not work around this bug. (NB: This bug was found previously by Tara at climbtothestars.org.)

Final block element inside absolutely positioned element has margins outside its parent

An example of this bug is shown in the same page as the previous bug. The H3 and P elements are defined to have 10px and 30px of margin all the way around. However, there is no gap between the borders of these block elements and the bottom of the containing innerdiv. Instead, the margin is between the parent of the block element, and its parent. The same problem also affects top margins of children of elements where its parent is preceded in the markup by another block element with a margin.

This bug seems to be related to the margin protrusion bug identified by Philippe Wittenbergh, even though that bug is not specific to absolutely positioned parent elements.

Intermittent double linespacing on raw text inside relatively positioned blocks

As first diagnosed by “Big John” and demonstrated in this simple test page, there are intermittent problems with linespacing of raw text (that is, text not in another enclosing element) in relatively positioned DIVs with either margin or padding CSS styles. This bug manifests differently as you zoom text up and down, sometimes getting rid of the intermittent linespacing, but if you reload it comes back. Workarounds including putting all text in block elements like P (not relatively positioned), or putting padding on an outer DIV instead of margin on an inner DIV. This bug appears to apply to text inside all relatively positioned blocks, not just DIVs; at least one site has reported the same problem for heading and paragraph blocks. This is particularly relevant for Web authors using the fix for a scrolling bug in IE6/Windows.

Problems with text-indent, line breaks and images

Phillipe Wittenberg has identified another text layout bug in Mac IE 5. As demonstrated in this test page, a paragraph with text-indent style and a line break on the first line immediately followed by an inline image (on the second line), will incorrectly have the text-indenting also applied to that second line of text.

A related bug was identified by Jeffrey Zeldman following a glitch in the formatting of a story on AListApart. In this version of the bug, paragraphs with the text-indent style specified in percentage units would lose that styling if there was a link at the beginning of the paragraph. Hovering over the link would reflow the paragraph and restore the correct indenting. Text-indents specified in ems and other units are not affected. The bug only applies to versions 5.1x of IE/Mac, not version 5.0.

In addition, links at the beginning of paragraphs with positive text-indent are subject to the same phantom link bug that applies to centered and right-aligned text.

Phantom Links (and quotes) in Floated DIVs

If text in a floated DIV is right-aligned (text-align:right;), or centered, any links in the DIV also generate active areas in the empty left-hand region of the DIV, as if the text was left-aligned. This can be clearly seen in this minimal testcase. As the testcase shows, dummy text before the links stops this bug activating. A similiar problem occurs with the <Q> element. It is as if IE lays down the behaviours of the inline element – its “linkness”, the quote marks around it – before actually working out where the text should go.

As demonstrated by Eric Meyer, this issue also arises in tables, even though these are not floated. Thanks to Kevin Smith for the link. This may be what is causing IE5/Mac’s incorrect presentation of our “E-mail this story to a friend” buttons here at MacEdition.

The issue also seems to arise when the text-indent style is used on paragraphs.

Link cursor properties not honored when inside a parent element with fixed positioning

Links inside fixed-position elements have no visual feedback that they are links, except by clicking or tabbing. The hover property does not work, nor does the normal cursor feedback. Normally the cursor changes to a pointer or hand when you mouse over a link, but this does not occur here. While IE5.1 does support the cursor CSS2 property, it does not seem to work if the links are inside an element with position:fixed.

An example of this can be seen in this simplified version of the gorgeous layout of James Bachman’s blog, Gas Giant. The bottom paragraph with the design credits is set to have a crosshair cursor; this verifies that IE5.x supports the cursor property.

Backslash in comment kills next style rule

As demonstrated by Sam-I-am and in a similar page here, IE5.x/Mac ignores the rule immediately following a CSS comment with a backslash in it, if that rule starts with either a stop or hash – that is, if it is a declaration for a class or id, without any other kind of selector modifying it on the left. This is a bug, but may have constructive application for hiding particular style rules from these browser version.

Problems with overflow

IE5/Mac has problems with the CSS2 property overflow and the auto value. For items with fixed height, this should result in a scrollbar being present if the content of the element takes up more space than the specified height. A workaround is available at Sam-I-Am.com.

Peter-Paul Koch has identified additional problems with IE5/Mac’s handling of the overflow property. From his site:

• A body {overflow: hidden} declaration is carried on to the next page in a frameset. This means that a user clicking a link from a framed page with hidden overflow doesn’t see scrollbars on the next page either, even though the page may need them and has no overflow declared.
• When using overflow: auto for an element inside a page, the page nonetheless becomes long enough to contain the entire content of the element, even though part of it is hidden. This creates unwanted scrollbars when the DIV goes towards the lower edge of the page. If the DIV is sufficiently smaller than the page everything works correctly.

In addition, DIVs with overflow:scroll do not seem to scroll background images, as shown in this test page at Peter-Paul’s site. Instead, the background image appears as if thebackground-attachment:fixed style has been applied.

Finally, setting html, body { overflow: hidden; } will hide the entire page from IE5/Mac, not just the bits outside the original viewport. Note that this style is a good way to make your content inaccessible to people with small screens or browser windows sized at less than full screen, so you might just want to avoid such a style in the first place.

Default border width not honored on tables and table cells

As demonstrated in a test page by Eric Meyer, IE5/Mac does not honor the default width of medium for borders on tables and table cells with the other styles set, eg as border: solid green;, even though this works for other block elements like P. IE versions 4.5 and 4.01 for the Mac do not suffer from this problem.

Centering tables requires long-form margin styles

As demonstrated in this simple example page, IE5/Mac centers tables using the correct margin styles if they are written in long-form as margin-left:auto; margin-right:auto;. The shorthand forms such as margin:0 auto; do not work. Fortunately this bug is easily worked around by using the long-form syntax.

Thanks to Nick Theodorakis whose efforts to find the most effective way to center a table with CSS were the spur to finding this particular bug.

Whitespace parsing substring bug

This is a problem with IE5/Mac’s HTML parser as much as with its CSS implementation, but it causes problems with CSS all the same. Whitespace before or after a class name will cause the element to pick up styles of another class if the class name used happens to be a substring of another class name defined in the stylesheet. This is particularly problematic for the use of multiple classes. See this test case for more information.

Small caps text word-spaced when it should be letter-spaced

As demonstrated in another test page by Eric Meyer, IE5/Mac word spaces text that should be letter-spaced, if it is also styled as font-variant: small-caps;.

Form element ordering determines background coloring (IE 5.1 OSX only)

This bug seems to be specific to the OS version of IE5.1. As demonstrated by this test page constructed by Philippe Wittenbergh, form elements such as checkboxes and radio buttons replicate the background color of preceding text input boxes, even though the checkboxes do not have the class attribute that generates the style in question (see screenshot at the same site). This bug does not apply to the Mac OS 9 version of IE5.1 (5.1.3 or 5.1.4).

The Huge Text Modulus Bug

First reported by Garrett Smith, it appears that IE5/Mac only supports text up to 256 pixels in size. Font-size specifications greater than this are treated as modulus(Z,256), where Z is the number of pixels you actually specified. This test page demonstrates the alarming effects this can have on text sizes very slightly above 256 pixels, 512 pixels, etc. The size unit does not matter; pt and em will have the same effect at equivalent size specifications.  While this will not affect a large number of sites in screen-based presentation, it could potentially have implications for print stylesheets intended for poster presentations and similar applications.