You’re viewing an archive of outdated material. Visit The Web Standards Project’s updated site to learn about our current mission.
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.
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.
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.
float.
(Screenshot: Part 1:
GIF;
Part 2:
GIF)
float.
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.
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.
vertical-align,
line-height and borders on inline level elements.
(Screenshot:
GIF,
PNG)
vertical-align.
line-height.
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.
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.
:link and :visited should be mutually exclusive
displayMacIE 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.
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.
white-spaceSupport 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.
first-line and first-letter pseudo elementsInternet 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.
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.