Tutorials Bugs Masterclass Free stuff Test pages Proposals

RichInStyle.com bug guide - Mozilla 5 & Netscape 6

Netscape 6 - the big picture

Netscape 6 has the best support for CSS (and indeed for almost every standard, thanks to its open development process, which gives standards concerns a high prominence) of any commercial browser (only Mozilla, the open version of Netscape, has fewer bugs).

With the Mozilla project Netscape dumped the horrendous rendering engine of Netscape 4 for a browser that had as a primary objective standards compliance. There is no doubt that this is a good thing, considering the untold millions Netscape 4 has cost in extra development to try fix its bugs - the only bad thing was that web developers have had to put up with Netscape for so long.

Netscape has been heavily criticized for its deficiencies. These criticisms do seem a little onesided however, given that the release of Netscape 6 is overwhelmingly good news for web developers, since support for things like the DOM mean that DHTML will no longer have to be rewritten with each new browser release (in fact many people have criticised Mozilla for this - saying that because it doesn't support the document.all object, which is just as proprietary as Netscape 4's layers, it therefore does not support 'DHTML').

Given that Netscape's focus on standards has been unprecedented, these criticisms are unbalanced, if not entirely unjustified (obviously any standards support problem is undesirable). In particular, it is easy to take an open bug database and pick some bugs and say that for those bugs the product should not be released - the openness of Mozilla does not help it from a PR point of view - when in fact every browser, every product ships with bugs - it's just that when (for example) previous buggy versions of Netscape shipped, there was not an open database from which to search for its problems.

Furthermore, it is important to emphasize that for every linux distribution that comes with Netscape 6 rather than 4, for every Windows user that upgrades their browser, and for every Netscape/AOL product that comes with a Gecko-based rendering engine rather than Netscape 4, there is one fewer headache for web developers, and one step closer to the time when huge savings in terms of development time, efficiencies from using CSS properly, can be truly realized.

Rather than giving the impression, which many people have received from the general hype surrounding Netscape, that Netscape 6 is not a standards-compliant browser, the true picture is that it is, the most compliant ever, but with some unfortunate, and highly noticeable thanks to Bugzilla, bugs, but them notwithstanding, the fact is that it is much, much, much better from a developer point of view for end users to be using Netscape 6 rather than 4, and the only way that this will happen is for Netscape 6 to be released.

Version tested

The information contained in this page is accurate for Netscape 6 (Mozilla build 20001108) (which has fewer bugs than Mozilla (81 rather than 86)), because fixed positioning was disabled). Thanks to the Mozilla bug sheet, it will be updated within a few days of each new milestone.


While it should be easily apparent what area you are using, and therefore which section you should read, everyone uses Section A and Section B, so therefore everyone should read these sections.

Bugs by type

Part 0 - Core issues - everyone must read

Section A - Bugs relating to the attachment of style sheets to pages (4 bugs)

Section B - Bugs relating to the application of styles to elements (2 bugs)

Section C - Key concepts (3 bugs)

Part 1 - Topic related issues - must read if you use the section involved

Section E - Color and background bugs (0 bugs).

Section F - Font bugs (7 bugs)

Section G - Text bugs (6 bugs)

Section H - Float bugs (5 bugs)

Section I - Positioning bugs (0/5 bugs)

Section J - Dynamic effects bugs (7 bugs)

Part 2 - Element related issues - must read if you use the elements involved

Section K - List item bugs (6 bugs)

Section L - Horizontal rule bugs (2 bugs)

Section M - Table bugs (9 bugs)

Section N - Form bugs (6 bugs)

Part 3 - Error correction bugs - bugs, but inconsequential unless you produce invalid style sheets

Section O - Error correction bugs (24 bugs)

Total bugs = 4 + 2 + 3 + 0 + 7 + 6 + 5 + 0/5 + 7 + 6 + 2 + 9 + 6 + 24 = 86/81.

Part 0 - Core Issues - MUST READ

Section A - Attaching style to pages

Alternate style sheet
Bug 1: title attribute treated as case-insensitive

Mozilla treats the title attribute, as used on LINK, as case-insensitive (it also treats it as case-insensitive for the attribute selector).

Style attribute
Bug 2: Specificity wrong

Mozilla gives the style attribute infinite specificity instead of 100, as is technically correct. This is a non-serious bug however, and should not be fixed.

Disabling style
Bug 3: can't disable style sheets

Mozilla does not allow style sheets to be disabled; this is required by the CSS specification.

Media case-sensitivity
Bug 4: ignored

Mozilla treats the media attribute as case-insensitive.

Section B - Applying style to pages

Bug 1: margin-right not supported

Although Mozilla supports padding and margin-left on :first-letter, it does not support margin-right.

Bug 2: local hrefs not marked as visited

Mozilla fails to mark local hrefs as visited unless clicked and then reloaded. This makes the functionality effectively useless. [Note, CSS does not define the status of links.]

Section C - Key concepts

Bug 1: not supported inside simple selectors

Mozilla does not support comments inside simple selectors (e.g., P/* */.class).

Transitional or no DTD
Bug 2: triggers hundreds of page destroying bugs

If you specify the transitional DTD (using <!DOCTYPE ...), or you don't specify a DTD at all, Mozilla triggers 'compatibility' mode. This brings with it countless page-destroying bugs in an effort to be compatible with Netscape 4.

Part 1 - Topic related issues - must read if you use the section involved

Section E - Color and background bugs

Section F - Fonts

Font sizes
Bug 1: larger buggy

Font-size: larger is buggy, failing to result in the next largest font keyword (e.g., small over x-small).

Font weights
Bug 2: bolder rendered as bold

Mozilla renders bolder as bold.

Bug 3: numeric font weights 600-900 rendered as plain bold

Mozilla does not support the numerical font weights, instead rendering 600-900 as bold and 100-500 as normal.

Font styles
Bug 4: oblique rendered as italic

Mozilla renders font-style: oblique as italic. This is wrong because the CSS spec states that "'italic' will be satisfied if there is either a face in the UA's font database labeled with the CSS keyword 'italic' (preferred) or 'oblique'. Otherwise the values must be matched exactly or font-style will fail."

Bug 5: line heights not correctly handled

Mozilla does not handle the following code correctly, overlapping only the descenders rather than more than that as it should:

<div style="margin: 100px 0; line-height: 0">
<span style="line-height: 5px; font-size: 205px">gggg</span><br>
<span style="font-size: 205px; line-height: 205px">AAAA</span>

Bug 6: height of line boxes containing replaced elements wrong

Mozilla gets the height of line boxes that contain replaced elements wrong (but only minorly - it won't affect non-precision applications) - it tends to get them a couple of pixels wrong.

Font families
Bug 7: must be lowercase

Mozilla requires generic font families (e.g., sans-serif) to be in lower case, even though, as with all CSS keywords, they are case-insensitive.

Section G - Text bugs

Bug 1: justify doesn't suppress word-spacing

When letter-spacing is explicitly set and text-align: justify, word-spacing should (per the spec) be ignored. However, Mozilla does not do so. This is arguable behavior, because it roughly honors the word spacing but still justifies; however, it is in breach of the plain words of the spec.

Bug 2: size of text decoration that of descendant element, not ancestor

Mozilla determines the size of text decoration by that of the descendant element, not that of the ancestor. For example, <P style="text-decoration: underline; font-size: 12px"><SPAN style="font-size: 100px">, which should result in the text decoration being the size appropriate for the ancestor, actually results in the size appropriate for the descendant.

Bug 3: inherited to block descendants

Although the CSS specification states that text-decoration is only inherited to inline descendants, Mozilla inherits it to block descendants.

Bug 4: sub and super move box, not baseline

In Mozilla, vertical-align: sub and super move the box, not the baseline - the spec states that sub and super move the baseline to the appropriate place for subscripts/superscripts of the parent box, but in Mozilla it moves the box so that the baseline is in the appropriate place for subscripts/superscripts.

Bug 5: ƒ uppercased results in nothing

ƒ uppercased results in nothing. This is incorrect because although part of Latin Extended-B, which need not be text transformed (only Latin-1 is required), it should, at worst (if the UA doesn't want to text-transform it), be left as-is rather than hidden. Note, incidentally, that Mozilla does tranform Greek letters (which are optional), but leaves Latin Extended-A as-is.

Bug 6: not applied 'outside' of elements

Where an element is a word, Mozilla will not check outside it to see whether it is so, and therefore word-spacing will not be applied.

Section H - Floats

Bug 1: inline right floats moved down a line unless they are the first thing in their line

Mozilla does not float right floats to the right of their line unless they are the first thing in their line; for example, Some text <SPAN style="float: right; width: whatever"> doesn't work correctly, but the same thing with the right-float as the first thing on its line works fine.

Bug 2: text only flows around one side of a float

Mozilla only supports text flow on the opposite side of a float to that float's type; for example, given a left-floating element, it would only wrap content to the right of that float.

Bug 3: where a non-floated element wraps around a left-floated element, one line box of it will overlap any right-floating element when so doing

When a non-floating element is wrapping around a left float and a right float is below that, then the float will overlap with the right float. For example:

<div style="float: left; width: 50%; border: solid 2px green">
First line text.
Second line text.
<div style="float: right; width: 50%; border: solid 2px green">
First line text.
Second line text.
<div style="border: solid thin red">
Although this element will correctly wrap to the right of the left float, when it gets to the right float (which will be below the left float (correctly, since 50% + 2px takes up more space than is available, and so it therefore goes below it)), it will overlap a little.

The problem seems to be that although the browser checks whether the top of the line box overlaps with said right float, it does not check that, by the time it gets to the bottom of the line box, that it is overlapping with a float below it. As a result, one line box (and its content) will overlap with the right float. Subsequent line boxes will flow correctly, however (this bug would also occur with a right float followed by a left float).

Bug 4: floats incorrectly aligned

Mozilla has problems with the alignment of floats. See test page and also: test page 2.

Bug 5: horizontal rules shortened

When horizontal rules overlap with floats, they are shortened where they overlap.

Section I - Positioning

Fixed positioning

Fixed positioning was disabled for Netscape 6.

Bug 1: fixed positioning suffers bad scrolling problems

When certain fixed positioning examples are scrolled, the text scrolls but the old text doesn't move so the appearance is of an ever growing blur. See: one of RichInStyle.com's test pages.

Bug 2: BODY's margin applied in some cases.

Even though BODY's margins should not apply to fixed elements since these are positioned relative to the left of the viewport, in some cases they are. See: one of RichInStyle.com's test pages.

Bug 3: scrollbars appear and disappear at random.

For some reason when certain scrollbars are clicked, they disappear, or else the menu appears on top of the document (i.e., File/Edit (or local/platform-equivalent)). See: one of RichInStyle.com's test pages (the footnotes section at the bottom, which should have a scroller - try clicking it).

Bug 4: fixed content sometimes completely ignored - not rendered

Under certain circumstances the specified content simply won't be rendered - see one of RichInStyle.com's test pages.

Bug 5: stacking order of fixed elements buggy

See one of RichInStyle.com's test pages, which has the fixed elements overlaying content that occurs later (the content that says 'This is filler') than them in the document tree, which is wrong since default stack order is document tree order in the absence of a contrary declaration.

Section J - Dynamic effects

Bug 1: invert unsupported

Instead of supporting outline-color: invert, Mozilla will treat 'outline-color: invert' as a transparent outline. In addition, it defaults to a black outline.

Bug 2: outline property only works if a color is specified

If you use the outline property, since outline resets to 'invert', the outline won't work unless you specify a specific color.

Bug 3: outlines on inline elements rendered as a border per line box

Whereas outlines on inline elements should in fact be rendered as the minimum connector that encloses the text, in Mozilla they will be drawn as a fully enclosed border per line box. Thus if you have an inline element that is formatted on two lines, it will be rendered thus:

|The text |
|on two lines|

rather than:

|The text|___
|on two lines|

Bug 4: cursor: url() unsupported

Mozilla does not support cursor: url().

Bug 5: cursor: auto unsupported

Mozilla does not support cursor: auto.

Bug 6: scrollbar on scroll and auto buggy

The scrollbar on overflow: scroll and auto is always initially at the top and left. This means that when content overflows to the left or top of an element, it cannot be viewed.

Bug 7: scroll and auto break clip

Mozilla breaks clip when overflow: scroll or overflow: auto, treating the clipping region as no clipping region at all when either setting is set.

Part 2 - Element related issues - must read if you use the elements involved

Section K - List bugs

Display: list-item
Bug 1: all ordered types rendered as 0

When you specify display: list-item, all ordered list style types result in 0.

List style types
Bug 2: dot placed after marker on ordered list types

Mozilla places a dot after the list marker on ordered list types; for example, it renders 1., 2., 3. instead of 1, 2, 3. This is incorrect according to the spec (because to do so wrecks the content property).

Bug 3: upper-greek unsupported

Although Mozilla supports lower-greek, it does not support upper-greek.

List styling
Bug 4: text-align moves list marker

Mozilla allows text-align to move list marker boxes. This is incorrect because marker boxes' (which are generated when list-style-position: outside, the intial value) position are not affected by the text-align of the principal box.

Bug 5: clear not supported on LI

Mozilla does not support clear on LI.

Bug 6: list markers aligned with the bottom of the collapsed margin between it and the previous element rather than with the first line box in the principal box

Instead of aligning the baseline of marker boxes with the baseline of the first line box in the principal box, Mozilla instead aligns it at the bottom of the collapsed margin between it and the previous element. Thus given <LI>Content<LI><P>More content, the marker box would be aligned with the bottom of the collapsed margin with the previous LI rather than with the baseline of the P (which is the first line box in the principal box).

Note that this might be indicative of more general problems with parent/child margin collapsing.

Section L - Horizontal rule bugs

Bug 1: padding applied incorrectly to horizontal rules

Mozilla does not apply padding correctly to horizontal rules - vertical padding should increase the height of horizontal rules because it implements them as a border around whitespace, but doesn't, instead being treated as a margin.

Bugzilla entry: 2590.

Bug 2: border-color not applied to horizontal rules

Mozilla does not apply border-color to horizontal rules.

Bugzilla entry: 2590.

Section M - Table bugs

Bug 1: inheritance into TD and TH

Mozilla inherits all properties from BODY into TD and TH instead of from the ancestor; for example, <DIV style="font-size: 100px"><TABLE></DIV> would result in BODY's font-size being inherited instead of the parent element. This would apply equally to color or any other inheritable property.

This only occurs in compatibility mode.

Bugzilla entry: 1044

Bug 2: inheritance into CAPTION

Mozilla doesn't inherit into CAPTION at all, instead always applying its browser-default values.

This only occurs in compatibility mode.

Bugzilla entry: 1044 (only in passing).

Bug 3: not supported on columns

Mozilla does not support backgrounds on columns.

This only occurs in compatibility mode.

Bug 4: transparent on tables

Mozilla makes table padding transparent instead of giving it the table's background-color.

This only occurs in compatibility mode.

Bug 5: unsupported on table rows

Mozilla does not support padding on table rows.

Bug 6: not supported on table cells or rows

Mozilla does not support positioning of table cells or rows.

Bug 7: widths clipped to avoid overflowing BODY

Mozilla clips table element widths to prevent them overflowing BODY unless the width specified is actually needed; for example, TD {width: 1000px} would be clipped to prevent the table overflowing the BODY. It does not, however, clip widths when the width of the content requires it.

Border spacing
Bug 8: made transparent

Mozilla makes border spacing transparent instead of giving it the color of the table.

This only occurs in compatibility mode.

Bug 9: completely broken

Mozilla's border-collapse: collapse implementation is completely broken. You can see a demonstration of this in one of RichInStyle.com's test pages.

Section N - Form bugs

Bug 1: background not applied to INPUT type="file"

Mozilla does not apply backgrounds to the text box or submit button of INPUT type="file".

Bug 2: line heights do not increase the size of INPUT type="text"

If you specify a line height that is too large on INPUT type="text", it will be honored but the height of the text box won't be increased to compensate, thereby rendering the text invisible.

Bug 3: line heights unsupported on INPUT type="password" or the text box on INPUT type="file"

If you specify a line height on INPUT type="password", Mozilla will ignore it. In addition, it does not apply them to the text box on INPUT type="file" (but it does not on the button.

Bug 4: white-space not supported on TEXTAREA

Mozilla does not support white-space on TEXTAREA.

Bug 5: padding destroyed on SELECT, OPTION and TEXTAREA

Mozilla destroys padding on SELECT, TEXTAREA and OPTION, breaking those elements when it is used. There is a demonstration in one of RichInStyle.com's test pages.

Bug 6: borders destroyed on INPUT type="password", type="text" and TEXTAREA

Mozilla destroys borders on INPUT type="password", type="text" and TEXTAREA, destroying these controls when it is used. There is a demonstration in one of RichInStyle.com's bug pages.

Part 3 - Error correction bugs - bugs, but inconsequential unless you produce invalid style sheets

Section O - validation bugs

  1. Mozilla fails to treat </ as terminating the STYLE element, as is specified by HTML [and therefore outside of the scope of the CSS specification].
  2. Mozilla allows character references in IDs, but they aren't valid there.
  3. Mozilla allows classes to begin with hyphens. (Bugzilla: 12385)
  4. It applies letter-spacing to :first-letter, but it shouldn't have an effect.
  5. It will render rulesets with missing closing braces
  6. It treats missing units as pixels when in compatibility mode.
  7. It applies white-space to inline elements, but it should only apply to block ones.
  8. It ignores rulesets that contain null selectors; for example, it ignores .class1, , .class2 {color: red}, which is incorrect because simple_selector is (partly) defined by element_name.
  9. It disregards the case of proprietary font names.
  10. It allows comments inside the URI token, which isn't valid - comments are only valid between tokens - not inside them.
  11. It allows more than one decimal place on rgb% (e.g., rgb(99.99%, 0%, 0%), but this isn't valid.
  12. It allows mixing of numbers and percentages; for example, it will render rgb(0%, 100, 100) as rgb(100, 100, 100).
  13. It allows non-integer values on rgb(nnn, nnn, nnn).
  14. It allows hidden (as none) on outline-style, but this isn't valid.
  15. It allows URIs other than first on the the HTTP Link header, which is invalid since Link is defined as "Link" ":" #("<" URI ">" *( ";" link-param ) ; i.e., URI MUST come first.
  16. It allows ' to be used as quotes around the REL value on the HTTP Link header, which is invalid (only " may be used).
  17. It will ignore rulesets that are associated with misplaced pseudo-elements. For example, given P:first-letter.class1, .class2 {color: red}, instead of treating the ruleset as .class2 {color: red} as it should, it instead ignores it entirely. This is demonstrably incorrect because the sole criterion for ignoring rulesets is that they cannot be parsed, and P:first-letter.class1 can be parsed (since the pseudo production is shared with pseudo-classes, and pseudo-classes before classes are valid).
  18. It makes this red P {/* \*/ color: red}
  19. It will apply :link:link as :link.
  20. It will apply fonts containg whitespace that aren't quoted.
  21. It will apply background: red !important url(back.jpg) as background: red whereas the declaration, being invalid, should be ignored.
  22. It has specificity problems: #id4 {color: red} .class .class .class .class .class .class .class .class .class .class {color: blue} should be blue but will be red.
  23. Provided the url is quoted, Mozilla allows comments inside the URI token, which is obviously invalid since they are only valid between tokens.
  24. Mozilla fails to ignore declarations that contain a line feed before the url in the URI token (such declarations are invalid and should be ignored; for example, this should have a plain background (background: yellow url("wood.jpg
    " );' - should be ignored: invalid).