|
|||||||
|
|||||||
|
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.
By Matthew Brealey.
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.
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)
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)
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)
Total bugs = 4 + 2 + 3 + 0 + 7 + 6 + 5 + 0/5 + 7 + 6 + 2 + 9 + 6 + 24 = 86/81.
Mozilla treats the title attribute, as used on LINK, as case-insensitive (it also treats it as case-insensitive for the attribute selector).
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.
Mozilla does not allow style sheets to be disabled; this is required by the CSS specification.
Mozilla treats the media attribute as case-insensitive.
Although Mozilla supports padding and margin-left on :first-letter, it does not support margin-right.
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.]
Mozilla does not support comments inside simple selectors (e.g., P/* */.class).
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.
Font-size: larger is buggy, failing to result in the next largest font keyword (e.g., small over x-small).
Mozilla renders bolder as bold.
Mozilla does not support the numerical font weights, instead rendering 600-900 as bold and 100-500 as normal.
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."
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>
</div>
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.
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.
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.
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.
Although the CSS specification states that text-decoration is only inherited to inline descendants, Mozilla inherits it to block descendants.
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.
ƒ 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.
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.
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.
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.
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.
<br>
Second line text.
</div>
<div style="float: right; width: 50%; border: solid 2px green">
First line text.
<br>
Second line text.
</div>
<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.
</div>
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).
Mozilla has problems with the alignment of floats. See test page and also: test page 2.
When horizontal rules overlap with floats, they are shortened where they overlap.
Fixed positioning was disabled for Netscape 6.
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.
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.
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).
Under certain circumstances the specified content simply won't be rendered - see one of RichInStyle.com's test pages.
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.
Instead of supporting outline-color: invert, Mozilla will treat 'outline-color: invert' as a transparent outline. In addition, it defaults to a black outline.
If you use the outline property, since outline resets to 'invert', the outline won't work unless you specify a specific color.
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|
----------------+
Mozilla does not support cursor: url().
Mozilla does not support cursor: auto.
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.
Mozilla breaks clip when overflow: scroll or overflow: auto, treating the clipping region as no clipping region at all when either setting is set.
When you specify display: list-item, all ordered list style types result in 0.
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).
Although Mozilla supports lower-greek, it does not support upper-greek.
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.
Mozilla does not support clear on LI.
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.
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.
Mozilla does not apply border-color to horizontal rules.
Bugzilla entry: 2590.
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
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).
Mozilla does not support backgrounds on columns.
This only occurs in compatibility mode.
Mozilla makes table padding transparent instead of giving it the table's background-color.
This only occurs in compatibility mode.
Mozilla does not support padding on table rows.
Mozilla does not support positioning of table cells or rows.
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.
Mozilla makes border spacing transparent instead of giving it the color of the table.
This only occurs in compatibility mode.
Mozilla's border-collapse: collapse implementation is completely broken. You can see a demonstration of this in one of RichInStyle.com's test pages.
Mozilla does not apply backgrounds to the text box or submit button of INPUT type="file".
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.
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.
Mozilla does not support white-space on 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.
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.
Copyright © RichInStyle.com 2000; all rights reserved. See copyright document for terms of use. Please visit Bukit Lawang flood appeal.