WinIE4 and WinIE5 both import files even when the @import statement is at the end of the document stylesheet. This is technically in violation of the CSS1 specification, although obviously not a major failing; thus the "Quirk" rating.

Navigator 4 has particular trouble with list items, which is most of the reason for the B.

Navigator 4's inheritance is unstable at best, and fatally flawed at worst. It would take too long to list all occurrences, but partiularly troublesome areas include tables and lists.

WinIE4/5 allows class names to begin with digits; this is not permitted under CSS1.

WinIE4/5 allows ID names to begin with digits; this is not permitted under CSS1. All browsers apply the style for a given ID to more than one instance of that ID in an HTML document, which is not permitted. This is properly an error-checking problem, and not a failing of the CSS implementations, but I feel it is significant enough to warrant the ratings shown.

MacNav4 has the most trouble with contextual selectors involving tables. For example, HTML BODY TABLE P is not properly handled.

Again, there are simply far too many instances of problems to list here.

Despite a preferences setting for cursive fonts, Opera does not seem to apply the perference, but instead substitutes another font.

IE4/5 approximates the small-caps style by making all such text uppercase. While this can be justified under the CSS1 specification, visually, it does not render the text in small caps.

IE4/5's values for absolute sizes assigns small to be the same size as unstyled text, instead of medium, as one might expect. Thus, declaring an absolute font size (such as font-size: medium will almost certainly lead to different size fonts in Navigator and Explorer. While this is not incorrect under the specification, it is confusing to many authors.

Nav4 does not apply the background color to the entire content box and padding, but rather just to the text in the element. This can be worked around by declaring a zero-width border.

Nav4 insists on applying this value to the parent of an element, not the element itself. This can lead to 'holes' in the parent element's background.

Opera 4 has a bug which only shows up when a background has been repeated, and the rest of the background of the element is transparent (either by default or when explicitly declared). Scrolling the element "offscreen" and then bringing it back can cause "holes" to be punched through the repeated images of ancestor elements, thus creating visual anomalies.

WinIE4 only repeats down and to the right. The correct behavior is for the background image to be tiled in both vertical directions for repeat-y, and both horiztonal for repeat-x. Nav4 gets this property correct on a technicality: since it does not support background-position, there is no way to know whether or not it would tile in all four directions if given the chance, or instead emulate WinIE4's behavior. Opera 3.6, MacIE4.5, and WinIE5 all behave correctly.

WinIE4 only repeats to the right, instead of both left and right.

WinIE4 only repeats down, instead of both up and down.

According to the specification, if an element is is decorated, but one of its children is not, the parent's effect will still be visible on the child; in a certain sense, it "shines through." Thus, if a paragraph is underlined, but a STRONG element within it is set to have no underlining, the paragraph underline will still "span" the STRONG element. This also means that the underlining of child elements should be the same color as the parent element, unless the child element has also been set to be underlined.

In practice, however, setting an inline element to none will turn off all decorations, regardless of the parent's decoration. The only exceptions to this are Opera and IE5/Mac, which implement this part of the specification correctly. Unfortunately, Opera 4 and 5 and Netscape 6 will not "span" inline images with the text decoration of a parent element. In addition, Netscape 6 appears not to use the parent element's decoration, but instead "replicates" the underline onto child elements, which is clearly wrong. Despite its seeming simplicity, this property remains a thorny problem for browser developers.

Since this value is not required under CSS1, only Navigator supports it (surprise).

Opera 3.6 uppercases the first letter in each inline element within a word, which (according to the CSS1 Test Suite) it should not do.

In Nav4, this value has a tendency to break down in tables, but generally works in other circumstances.

Nav4 incorrectly permits negative values for this property.

Opera 3.6 almost gets inline right, but seems to honor the occasional carriage return as though it were a <BR> element, instead of plain whitespace.

MacNav4 displays question marks for bullets when using this value.

The positioning and formatting of list-items when set to this value are a bit odd under MacIE4.

All supporting browsers appear to calculate ex as one-half em. This is arguably a reasonable approximation, but it is technically incorrect.

Navigator will generate a color for any apparent keyword. For example, color: invalidValue will yield a dark blue, and color: inherit) (a valid declaration under CSS2) comes out as a vaguely nauseous green.

Navigator determines relative URLs with respect to the HTML document, not the stylesheet.