MacIE's Top 10 CSS Problems

This is the third of a series of WSP standards-compliance reviews. As a matter of policy, the WSP provides thorough coverage of and feedback on interim releases of major browsers. The first was a review of Windows Internet Explorer released in early November 1998, and the second was a review of Opera released in early February 1999.

Introduction

Microsoft recently released Internet Explorer 4.5 for the Mac. This release makes significant improvements in many areas of CSS support. In some areas (including some of the problems we described) it is better than Internet Explorer 5.0 for Windows.

On the Macintosh, it offers by far the best support for CSS1 in a publicly released browser. However, it still has significant problems. Its support for the visual formatting model is weak in some areas. Margins and widths are calculated incorrectly, and floating elements cause strange side effects. Styles applied to inline elements are interpreted incorrectly. It has serious problems in parsing the CSS language (and the seriousness of these last problems will only become fully apparent when they break new features added to the CSS).

It also lacks important features of CSS1. The display property is only partially supported, and a few others are not supported at all. There is no user interface for the selection of alternate stylesheets, an interesting and useful feature of CSS1 and HTML 4.0.

The implementations of CSS1 in major Web browsers over the last three have been buggy and incomplete. These implementations have caused great frustration and expense for Web authors, have won CSS an undeservedly obscure and difficult reputation, and have left many of its features unusable. CSS is more than just the small step above the font tag allowed by current browsers. It is a powerful language that combines different suggestions for the presentation of semantic markup.

Now that Netscape promises to release a comprehensive and thoroughly tested CSS1 implementation in the near future (which we will be examining in depth in due course), the WSP calls upon Microsoft to improve its implementation, letting Web designers, authors, application developers, and users build upon a single, robust foundation for Web presentation: CSS1.

The Top 5 Bugs

1. Problems with float

MacIE has some mysterious bugs related to the float property. Adjacent floated paragraphs may overwrite each other or text around them, floated elements may be placed in incorrect positions, and floated images may overlap surrounding text. In certain cases, text that is floated causes a line break in its container. This bug makes floats within text very difficult to use. Sometimes floating an image can even cause a link not to work. Taken as a whole, these bugs change floating from a safe and easy method for creating out-of-flow content to a risky and difficult one.

  1. Demonstration of problems with float. (Screenshot: Part 1: GIF; Part 2: GIF)
  2. Demonstration of problems with line breaks around float.
  3. Demonstration of problems with floating images and floating links (Screenshot: GIF, PNG)
  4. Demonstration of overlapping and incorrect layout of floats. (Screenshot: GIF, PNG)
  5. Demonstration of strange horizontal indents around floats

2. The Block Level Box Model

MacIE does not follow the rules for for calculating margins and widths of elements described in section 4.1.2 of CSS1. Problems appear particularly when one or more of those values is set to auto. For example, when an element's width is set bigger than its containing block, it should be bigger than its containing block (and have a negative margin). MacIE incorrectly widens the containing block instead. That is, it incorrectly lets the contents of a block box affect its dimensions, something that should only happen when height is auto.

MacIE also interprets the margin and padding shorthand properties incorrectly, applying them to the top and left only.

Furthermore, MacIE does not support any of the box model properties on the body or html elements. This deficiency forces authors to create additional markup for the sole purpose of styling that markup.

  1. Containing block is widened by contents.
  2. Margins set to auto give incorrect layout. (Screenshot: GIF, PNG)
  3. Shorthand problems on margin and padding. (Screenshot: GIF, PNG)
  4. Demonstration of problems with box model properties on body and html.

3. The Inline Level Box Model

The various margin and padding properties have serious problems on inline elements. Side margin and padding should cause spaces at the beginning and end of an inline element. MacIE instead puts the indents at the beginning and end of every line but the first that the inline element occupies (and in both cases these indents act like margin, never padding). When the inline element begins a block box, the box properties of the inline element affect the containing block box. Top and bottom margin on inline elements correctly have no effect in MacIE. However, top and bottom padding, which should extend the background of the inline element without changing the line-height, also have no effect, except to increase the line-height.

Furthermore, the vertical-align and line-height properties are only partially implemented, which prevents complex text layout from being achieved, and the border property appears to be ignored on inline text.

Rather than basing calculations of the vertical alignment of replaced elements on the size of the font of the parent element (where applicable) calculations are based on the size of the font of the tallest element in a line. While this is the correct basis for values of top and bottom, it yields incorrect results for the vertical-align values baseline, middle, text-top and text-bottom.

MacIE does not let the computed value of the line-height property (when set by percentage) inherit. Instead, it makes the specified value given by the stylesheet author inherit. This is incorrect, as the specified value should only inherit when given as a dimensionless factor. It misleads authors by making them think that percentage and em units for line height are equivalent to the much safer dimensionless factors.

  1. Demonstration of problems with margin and padding on inline level elements. (Screenshot: Part 1: GIF, PNG; Part 2: GIF, PNG) See also the reference rendering (GIF, PNG) which corrects every problem except for extra spacing at the ends of lines.
  2. Demonstration of problems with vertical-align, line-height and borders on inline level elements. (Screenshot: GIF, PNG)
  3. Demonstration of problems with vertical-align.
  4. Demonstration of problems with line-height.

4. Parsing and Error Handling

MacIE's CSS parser has major faults in its error recovery code. The CSS1 specification explains very clearly how unrecognized CSS should be handled (i.e., what to ignore). MacIE does not follow this part of the recommendation. Documents designed for future levels of the CSS specification will thus be displayed incorrectly, and sometimes bizzarely.

Some of the problems include incorrectly interpreting escaped braces ("\{"), accepting unknown or missing units (and interpreting them as pixels), allowing quoted values, and treating two consecutive slashes in a selector (//) as a comment delimiter instead of as an unknown selector symbol.

  1. Demonstration of problems with error handling.
  2. Demonstration of parsing bugs.
  3. Demonstration of parsing bugs with nested braces.
  4. Demonstration of error handling bugs with unsupported selectors.
  5. Demonstration of error handling bugs with unknown units.

5. Link Pseudo Classes

MacIE has problems handling the pseudo-classes used for selecting links. If multiple pseudo classes are given, it applies the style rule as if only the last pseudo-class given were present. It should either ignore the rule completely (CSS1) or require that the elements match all the pseudo-classes (CSS2). Furthermore, while :link and :visited should be mutually exclusive, it allows elements that match :visited to match :link as well.

  1. Demonstration of link problems. - :link and :visited should be mutually exclusive
  2. Demonstration of problems with multiple link pseudo-classes.

The Top 5 MIAs

1. display

MacIE only supports one of the four values for the display property: none. This leaves block, inline and list-item unsupported.

inline is needed to allow a correct combination of logical markup and display. For example, an unordered list should by contained in a UL element, but the author may want that list displayed on one line. The display value of inline allows the correct combination of logical markup with style. The block value allows the opposite effect.

This document has manually numbered H3 elements. If the list-item display type were supported for H3, the UA might generate the numbering as with any other list, thus alleviating the burden on the document author to have to keep the numbering in check.

CSS2 introduces a number of new values for the display property. While these values will also be useful, we believe designers would rather see them postponed in favor of complete support for the CSS1 values.

  1. Demonstration of display.

2. Alternate stylesheet UI

CSS1 allows authors to associate multiple stylesheets with a document, allowing users to choose the most appropriate or pleasing.

For example, a designer could create a default "public" stylesheet for a body of documents, a second sheet suitable for intra-organizational or -departmental access to the same documents, and a third suitable for users who are visually impaired (using high-contrast colors, for instance). The mechanism is extensible to include transparent application of media-specific stylesheets: one for print, one for WebTV, another for hand-held device browsers - all without content redundancy. This document, for instance, written in HTML 4.0 Strict, is associated with three distinct stylesheets. Unfortunately, due to lack of support for this CSS1 feature, you are unlikely to have any choice but the default, or no stylesheet at all.

Among the primary design goals of CSS is to restore balance among the responsibilities the author, the user, and the user agent (UA; i.e., the browser) must share when negotiating the presentation of Web content under varying conditions. These goals require the ability to specify a user stylesheet, the ability to disable author style sheets, the exposure of alternate author style sheets, the ability to change user stylesheets quickly, and the exposure of a UA default stylesheet for each media type.

By not implementing a user interface for alternate and user CSS, MacIE turns CSS from a language designed to balance user and author needs into a fundamentally user-hostile instrument. With users unable to interact with CSS easily, authors are not only entertained with the promise of reckless authority in matters of style, but are also tempted to create documents that lack structural markup and are thus meaningless with any stylesheets other than their own.

  1. Simulation of Alternate Stylesheets.

3. white-space

Support for CSS1's nowrap value of the white-space property would permit retirement of the nonstandard NOBR extension and the deprecated NOWRAP markup attribute, as required by HTML 4.0. Control over whitespace preservation with the pre value would help further abstract presentational considerations from markup.

  1. Demonstration of white-space.

4. No first-line and first-letter pseudo elements

Internet Explorer for the Macintosh still does not support CSS1's first-line and first-letter pseudo elements. Opera and the pre-release version of Netscape's next browser both support this property. This missing feature will result in pages looking duller on Microsoft's browser.

  1. Demonstration of first-line and first-letter.

5. The important Priority

MacIE does not support the ! important priority, which can raise the level in the cascade of a declaration. This is not a serious omission now, since MacIE does not yet support user stylesheets. However, it is vital once user stylesheets are implemented.

  1. Demonstration of important priority.