Tutorials Bugs Masterclass Free stuff Test pages Proposals

RichInStyle.com bug guide - Netscape 4: Part 1

Netscape at a glance

Safe to use

Unsafe or won't work

Every other property. (Read instructions below first).


Do not use ever:

Use with impunity:

Read the instructions first:


My policy on bug testing is to test to the highest version of CSS that the browser supports some part of, and as such I have tested Netscape for CSS 1 and CSS P compliance, plus HTML insofar as it impacts on CSS.

These have been newly re-sorted into categories. This should make it easier for to you find whether the property that you want to use works. The organisation is such that if a bug is with a particular property (e.g., margin-left), but only occurs when another property is used (e.g., float), then it is listed under the property that it occurs with.

The idea behind the reorganisation is to allow you to see at a glance all the bugs for the area of CSS that you are trying to use.

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.

Note that, unlike my other pages, this is not an exhaustive list of bugs, but I would estimate the total Netscape bug count at around 500. However, those bugs that are included make documentation of those that are not somewhat pointless insofar as other bugs make documentation of these bugs pointless.

Bugs by type

Topics to be found in this part of the bug guide

Part 0 - Core issues - everyone must read

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

Section B - Bugs relating to the application of style to pages ( bugs).

Section C - Bugs relating to key concepts ( bugs).

Section D - Bugs with units (2 bugs).

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

Section E - Font bugs (22 bugs).

Section F - Text bugs (17 bugs).

Section G - Color and background bugs (12 bugs).

Topics to be found in part 2 of this bug guide

Section H - Margin and padding bugs (15 bugs).

Section I - Border bugs (24 bugs)

Section J - Other bugs - positioning, display, and width (18 bugs)

Section K - Float and clear bugs (21 bugs).

Part 2 - Element-specific bugs - must read if you use the section involved

Section L - Table bugs (13 bugs)

Section M - Form bugs (10 bugs)

Section N - List item bugs (LI, DD and DT) (19 bugs)

Section O - Horizontal rule bugs (5 bugs)

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

Section P - Error correction bugs (42 bugs)

Total bugs = 30 + 2 + 22 + 17 + 12 + 15 + 24 + 18 + 21 + 13 + 10 + 19 + 5 + 42 = 250.

Part 0 - Core Issues - MUST READ

Section A - Bugs relating to the attachment of style to pages

Media attribute
Bug 1: only screen supported

Only style sheets declared as media="screen" are used, those declared for 'print' or 'all' won't be read.

This means that you shouldn't declare media="all" if you want Netscape to read the style sheet.

Bug 2: commas destroy

When the media attribute specifies a comma separated list of style sheets (e.g., media="screen, print") Netscape will ignore the style sheet.

Style attribute
Bug 3: specificity too high

Netscape gives the style attribute (e.g., <P style="color: red">) infinite specificity, but the spec states that it should be 100. However, this is one bug that should not be fixed, since the 'wrong' approach is the better one.

Bug 4: style specified inline on IMG

If an IMG has the style attribute set on it (even to nonsensical declarations), the image will be thrown around the page, styles will stop working and general chaos and page destruction will ensue. To avoid this bug, use a class instead.

Bug 5: background images specified inline destroy element

If you declare a background image via the background or background-image attributes, Netscape will destroy the element, ignoring all styles specified for that element and suppressing inheritance into the element.

To avoid this bug, use a class instead.

Disabling javascript
Bug 6: disables style sheets

Netscape depends on Javascript to render style sheets, so if you disable style sheets, it will also disable style.

Bug 7: missing style sheets destroy page

If an external CSS file is missing, the page will not be rendered.

Bug 8: not correctly order sorted

Per the CSS spec, embedded style sheets are ALWAYS read after LINKed ones. Netscape, on the other hand, reads them in the order they come in. This means that you should include them in the order you want them to be used. E.g.:

<STYLE type="text/css">
/* Should be read after the LINKed style sheet below, but isn't */

<LINK rel="stylesheet" type="text/css" href="name.css">

This becomes:
<LINK rel="stylesheet" type="text/css" href="name.css">

<STYLE type="text/css">


Alternate style sheets
Bug 9: not supported

Netscape does not provide any means to select alternate style sheets.

Bug 10: unsupported

Netscape does not support @import.

Section B - Application of styles to pages

Bug 1: A too specific

A is given greater specificity than A:link. This means if A is declared as well as A:link, A:link is ignored. Since A:link and A:visited do everything that A does, A is superfluous anyway, and so you should not declare A. E.g.:

A {color: red}
A:link {color: green}
A:visited {color: blue}
/* What is wanted is blue visited text, and green linked text.
What we will get is red visited, and red linked text. So: */
A:link {color: green}
A:visited {color: blue}
/* Equally: */
A {color: red}
#id .class A:link {color: green}
/* A is given the greater specificity! However: */ A.class
/* Or */
/* Is applied over */
A /* without id or class */

Bug 2: :visited

:visited is not applied to local hrefs (e.g., <A href="#"), but :link is instead (always).

Bug 3: :visited and :link

Netscape applies all declarations on A:link and A:visited (or :link and :visited) as if they were A, except for color, which it does correctly honor. These means that you should take great care with these declarations. For example:

A:link {font-size: 18px;
color: red;
text-decoration: underline}
A:visited {font-size: 10px;
color: green;
text-decoration: none}
Would be converted to:
A {font-size: 14pt;
text-decoration: underline}
A {color: red} /* Note not A:link */
A {font-size: 10px;
text-decoration: none}
A:visited {color: green}
Which is the same as (because of order sorting)
A {font-size: 10px;
text-decoration: none;
color: red}
A:visited {color: green}

As a result, you might find that it is simplest and least likely to lead to confusion if you declare A {everything except for color} A:link {color only} A:visited {color only}

Thus if you use these selectors, your <A name=""></A> anchors will be styled. For this reason, I recommend that you always make your anchors empty (e.g., <A name=""></A>).

Bug 4: specificity of A: and :

Netscape fails to distinguish between A:link and :link for specificity. Neither does it distinguish between A:visited and :visited.

Bug 5: unsupported

Netscape does not support :active.

Bug 6: unsupported

Netscape does not support :first-line.

Bug 7: unsupported

Netscape does not support :first-letter.

Classes and pseudo-classes

According to the CSS-1 spec, this was not valid - A:link.hello, but this was - A.hello:link. CSS 2 allows both. Netscape follows the second option.

HTML selector
Bug 8: not supported

Style is not applied to the HTML element. However, it is simple matter to change HTML {} into BODY {}.

Bug 10: not implied

According to the HTML specification, if you omit the <BODY> tag, its presence is implied.

Netscape does not follow this, and as such, you must include the BODY tag if you are intending to apply style to it.

Bug 11: ID selectors must include ID alone

IDs don't work unless the selector only includes ID; for example, DIV#id won't work, but #id will. In addition, #id.class won't work, .class#id and #id:link all will not work.

Bug 12: treated as case-insensitive

IDs are treated as case-insensitive, but the HTML specification states that they are case-sensitive.

Bug 13: treated as case-insensitive

Classes are treated as case-insensitive, but the HTML specification states that they are case-sensitive.

Bug 14: most non-alphanumeric characters destroy all styles

Although the CSS specification states that classes can contain characters other than letters and numbers, most such characters cause javascript errors in Netscape (since Netscape converts all CSS to JASS), thereby resulting in total loss of all javascript and style on that page. As a result, you are advised that you should only include numbers, hyphens and letters in classes (and remember that classes can't start with numbers or hyphens).

Bug 15: kills container

This screws up pages big time. When Netscape encounters NOSCRIPT, it correctly treats <NOSCRIPT> as though it wasn't there (if javascript is enabled), but fails to ignore the closing tag.

Unfortunately, where block elements are closed that weren't opened in Netscape, it closes the next higher block element, e.g., a redundant /P would be /body if the containing block was BODY (i.e., if the ancestor block element was BODY), and so it is with /noscript. Usually, NOSCRIPT will be in BODY, as in:


In this example, NOSCRIPT's container is BODY, and so BODY will be closed. This means all margins, all formatting information inherited from BODY, etc., will be lost. The only thing that is not lost is background information.

However, if you change NOSCRIPT's container, this problem is avoided.

For example,


In this case, /noscript is treated as /p, since P is its container. As a result, /p causes /body, since Netscape's behaviour when a closing tag appears for an element that isn't open is to close the current element, which in this case is BODY. As a result, if (what Netscape thinks is a second /P is removed), the problem is solved:


The problem with this solution is that P isn't really suited to this task - DIV is the appropriate element. However, unlike P, you can't omit DIV's closing tag. What you can do, however, is either:

<DIV class="body"> /* And add .body to the BODY selector */

Or: (better IMHO)


Note that you can't close the div after /noscript, since Netscape will interpret it as /body, so do it immediately prior to /body. Note also that Netscape will close the DIV on /NOSCRIPT, but other browsers will close it at the end of the document; Netscape thinks /div is incorrect, but since it is the last thing in the BODY, it doesn't matter.

Yet another alternative, and possibly the best one is to avoid specifying any formatting on BODY at all (except for background, which doesn't suffer from this bug). E.g.:

background: red;
margin-left: 10%; /* Would normally be specified on BODY */;
H1 {
margin-left: 7%; /* Outdented H1s */
P, H1, H2, H3, H4, H5, H6, (all block elements) {
all font and color information here

The great advantage of this method is that it avoids other bugs with Netscape, and also avoids bugs in Internet Explorer 3.00 that treated negative indents as relative to the left of the viewport. However, it does place certain demands upon your HTML, and if it does not meet these demands, this method is useless. E.g.:

Noscript content here
A heading here
Some text
New paragraph
New paragraph

This is wrong - 'Some text' is not enclosed in an element, and thus will not have any style applied to it.

Noscript content here
A heading here
Some text
New paragraph
New paragraph

This is right. Note that this method makes it imperative that you avoid the bugs (see under the box model) relating to margins/padding et al on LI, DD and DT and apply the appropriate properties to OL and DL instead.

Section C - Key concepts
Bug 1: ignored

Netscape does not weight sort.

Bug 2: destroyed

If there is a line break between the ! and the important, Netscape will ignore that declaration - wrong (to it) is !
important, but o.k. is !    important.

Bug 3: destroyed

Use of the backslash (e.g., for referring to unknown characters) is unsupported; furthermore, when used in a selector or property name, it causes a JavaScript error, which will break the whole page's style.

Bug 4: destroys

If you specify a value of inherit, it is rendered as #00e000 when specified on color or as a background color. On other elements, it is treated as initial_value; for example, font-family: inherit as font-family: initial.

Bug 5: not supported between ':' and IDENT on pseudo-classes

Netscape does not support comments between : and IDENT on pseudo-classes; for example, A:/* */link, would be ignored in Netscape.

Section D - Bugs with units

Bug 1: Relative units - what they relate to

Relative units that relate to font-size are very buggy.

The best way to see this is by this style sheet:

DIV.a, div.b, div.c {
border: solid thin;
div.a {font-size: 2em}
div.b {font-size: 200%}
div.c {font-size: 4ex}

And this BODY:

<div class="parent">
  <div class="a">
  <div class="b">
  <div class="c">

Box a is then the same size as box b, but box c is slightly smaller. Upping its font-size to a value between 4.14 and 4.15 ex (note that you can't change it that precisely) to make it the same size.

Next add DIV.parent {font-size: 1em} (note that BODY will also work because of inheritance).

Box b and box c are now the same size (box a is substantially smaller - see above). Increasing its font-size to a value between 2.1 and 2.2 em makes it the same size.

DIV.parent {font-size: 100%} has exactly the same effect (viz. making box a smaller).

Font-size: 2ex, on the other hand, has the same effect as having no font declaration at all.

Bug 2: Relative units - what they relate to

Now try this:

DIV.a, DIV.b, DIV.c, DIV.d {
border: solid thin;
BODY {font-size: 24px}
DIV.b {font-size: 1em}
DIV.c {font-size: 100%}
DIV.d {font-size: 2ex}

With this:

<DIV class="a">
This one has no font-size that applies to it.
<DIV class="b">
<DIV class="c">
<DIV class="d">

A, b and c should all be the same size, but they are not. A is much smaller than b, c and d, which are all of equal size. This indicates that although relative units relate in some measure to the inherited value, they do not do so properly - it seems that in addition to multiplying by one, they are multiplied by some constant. Some fiddling with DIV.a {font-size} shows that font-size: 31px makes it the same size as b, c and d. This suggests that this mysterious constant is 31/24 ≅ 1.3. Unfortunately, adding font-family: "Comic Sans MS" (or whatever) to the declaration makes this untrue and increases it to a much greater amount. A little experimentation shows that there is no relation whatsoever between the font's aspect value and this constant, and so therefore ex and em should be avoided at all costs, and % should be avoided on font-size and line-height.

Note that what things relate to sometimes depends on the previous element. Thus if H3 {font-size: in ems}, where two H3 elements are adjacent, the second one will be much larger than the first.

Line-height, margin, etc.

The ramifications of the bugginess of relative units are enormous. For example, line-height almost demands the use of relative units. The effect of adding 30% or more (depending on the font) to line-height can turn attractive pages into monstrosities. This means that under no circumstances should you use relative units on line-height. This may result in a large number of redundant declarations, since if you declare line-height on BODY, you will need a line-height declaration for BODY, plus one for each element that has a font-size different to BODY's. E.g.,

BODY {font-size: 16px;
line-height: 20pt}
H1 {font-size: 28px;
line-height: 34px}


To avoid this, I prefer to set line-height on the (more limited) number of elements that I feel really need it. E.g.:

BODY {/* No line-height declaration */}
P {line-height: 24px; /* line-height is most useful on P */}
OL, UL {line-height: 24px; /* Here we rely on inheritance to do what we want to be done to LI (it won't work on LI) */}
H1, H2, DIV, etc. {/* No line-height declaration - the default works fine */}

On other properties, the bug is less significant, e.g., on margin-left, but on something like P {margin-top: }, it could make a substantial difference to the page. In general, I would advise removing as many references to ems, exes and % as possible, preferably all of them.

However, if you really must set line-height in ems, exes or %, you will at least maintain proportion if you set font-size in the same unit (equally vice versa). This will cause everything to be too big, which is preferable to one being too big and the other being out of proportion. In addition, you should note that setting line-height in a unit that does not relate to font-size can cause problems where the user has adjusted their default font size (E.g., line-height: 18px where they have set their font-size to 24px). Thus you should also set font-size.

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

Section E - Font bugs

Font sizes
Bug 1: inheritance of relative units

Where any of an element's ancestors have their font-size specified in any relative unit (ems, exes, %) to any value, for the purposes of relative units, the element will think that it is a certain value (about 18px depending on the default font) that varies according to the user's default font - not according to the font-family). E.g.:

BODY {font-size: 100%} /* Could be any value.*/
DIV {font-size: 16px} /* To demonstrate that it is any ancestor */
P {font-size: 200px; /* To make the effects clear - it could be less (this bug is usually noticed on the H? elements) */
margin-left: 1em; /* Should result in a 200px left margin but actually about 18px */
border: solid thin;

This means that you should avoid font-size in %, em or ex in any of the following (in addition to avoiding them for countless other reasons on a greater range of elements):

Bug: font size relative to default value, not inherited value

On headings, Netscape interprets relative values relative to the heading default rather than the initial value. This means that you should use pixels if you want to change font sizes in Netscape.

Bug 2: adjacent font-sizes rendered as the same

Adjacent font-sizes (e.g., 15 and 16px, 13 and 14px) are applied as the same

Bug 3: larger and smaller

Although these have a constant scaling factor, they do not correspond with the font-size keywords. For example, font-size: larger applied over an inherited value of xx-small should result in small. Netscape doesn't apply this, always making larger a bigger jump than the next keyword up.

xx-small illegible

Netscape renders xx-small illegibly. Whilst this is not a bug, and I have not listed as such, it is worth bearing in mind.

Font styles
Bug 4: oblique destroyed

Netscape destroys font-style: oblique, rendering it as italic.

Font weights
Bug 5: lighter unsupported

Netscape doesn't support the lighter value.

Bug 6: bolder rendered as bold in some versions, unsupported in others

Netscape applies bolder as bold, so you should use a numerical font-weight and redundant selectors to achieve the desired weight (e.g., instead of STRONG {font-weight: bolder}, have STRONG {font-weight: bold} STRONG STRONG {font-weight: 900), etc.

Bug 7: normal, explicitly specified on ancestor element, suppresses default boldness of descendant elements

If you explicitly specify font-weight: normal on an element, descendant B and STRONG elements will not be bold unless you explictly set font-weight: bold on them; for example, BODY {font-weight: normal} would suppress B and STRONG's boldnes; B, STRONG {font-weight: bold} would restore it.

Font variants
Bug 8: unsupported

Netscape does not support font variants.

Font families
Bug 9: fantasy rendered as sans-serif

Fantasy is rendered as sans-serif (this is incorrect even if the browser has no fantasy font - it should either use the initial value or the inherited value).

Bug 10: glyphs not correctly matched

According to the CSS specification, where there is no matching glyph for the character requested in the suggested font, a font that does include the glyph should be used instead. While Netscape applies this for character references (such as &quot;, or &#67;), it does not do so for un-referenced characters, instead applying the glyph that is in the same position in that font as the requested glyph normally would be. Thus <SPAN style="WingDings">H</SPAN should result in a H, and WingDings should not be used since it doesn't contain any H's, but in Netscape it will result in WingDings. This means that you should be wary of specifying fonts that lack the appropriate glyph for un-referenced characters.

Note: PRE

PRE should have font-family: monospace by default, but doesn't in all versions, so you need to add this to your style sheet (providing you want PREformatted elements in monospaced font). (This not necssarily a bug).

Bug 11: half-leading suppressed adjoining border

Where a line box is inside an element with a border, the top half-leading is given the background of BODY where it adjoins the border.

Bug 12: doesn't work on inline elements

Line-height doesn't work on inline elements.

Bug 13: inheritance of relative units

Where any of an element's ancestors have their line-height specified in any relative unit (ems, exes, %) to any value, for the purposes of relative units, the element will think that it is a certain value (about 17px depending on the default font) that varies according to the user's default font - not according to the font-family). E.g.:

BODY {line-height: 100%} /* Could be any value. */
DIV {line-height: 16px} /* To demonstrate that it is any ancestor */
P {font-size: 200px; /* To make the effects clear - it could be less (this bug is usually noticed on the H? elements) */
margin-left: 1em; /* Should result in a 200 px left margin but actually about 20px */
border: solid thin;

This means that you should avoid line-height in %, em or ex in any of the following (in addition to avoiding them for countless other reasons):

Bug 14: normal

This is buggy - it doesn't work over inherited values:

P {line-height: 72pt;
line-height: normal;}
/* Works fine. */
/* But this doesn't: */
DIV {line-height: 72pt}
P {line-height: normal}

Thus although line-height: normal is applied by default, it will not be applied to override inherited values. This means you should specify a value for line-height in a unit (e.g., pt) in such cases.

Bug 15: set to normal when border set

When you set border on any element, line-height is automatically set to normal. This assumes greater significance because it is only by setting border that you can get background colors to work (see above). This can be fixed by setting margin-left or margin-right to any value. E.g.:

DIV.box {
line-height: 120px;
border: solid thin}

DIV.box {
line-height: 120px;
border: solid thin;
margin-left: whatever}

DIV.box {
line-height: 120px;
border: solid thin;
margin: whatever} /* including 0 */

Bug 16: <number> destroyed

Line-height: 1.6 (for example) should result in all descendant elements having a line-height 1.6 times that of their own (the descendant elements that is) font-size. However, Netscape applies it as line-height: 160% (which is buggy, see above). This means that you should either set line-height on each element individually, or stick with line-height: normal.

Bug 17: height of line box not adjusted

The height of a line box (that is to say the box that is the line) should be that of the element with the greatest line-height on that line. Netscape fails to apply this when line-height has been set to a value other than normal.

P {line-height: 18px}
<SPAN style="font-size: 72px; line-height: 78px; color: red">T</SPAN>he first sentence is here.

This example would result in the first line being thrown down a couple of lines, with the result of unsightly overlap. However:

P {line-height: 18pt}

P.containsbiginline {
line-height: normal;
<P class="containsbiginline">
<SPAN style="font-size: 72px; line-height: 78px; color: red">T</SPAN>he first sentence is here.

Bug 18: replaced inline elements

Where a replaced element is inline (e.g., IMG), if its height is greater than that of the line box, the line box height should be that of the replaced element. Netscape fails to apply this if line-height has been set on the element. This makes it inadvisable to apply line-height to elements that contain inline replaced elements. E.g.:

P {line-height: 16pt}
<IMG width="" height="">
/* Would work if P's line-height were omitted, or if you had P.containsimage {line-height: normal} */

Bug 19: all applied below line

Some versions of Netscape 4.0* apply all the line height below the line

Bug 20: incorrectly calculated

Netscape does not get line height right - the line box is usually a pixel or two out. This is not likely to affect much however, since this kind of precision is seldom required.

Bug 21: destroys all except px

Setting line-height in cm, mm, pt, pc or in on any element whatsoever will result in an extra page break before and after the element. Thus one page I printed was 1599 pages long.

To avoid this, you must use px, em, % or ex if your page's nature is such that it might be printed. However, em and ex are buggy, as is %, so you may wish to use only px. This is not such a bad thing as you might think, since using pixels allows you to ensure that the size is proportional to that which is appropriate for your reader's display - 25px will look just as appropriate on 1024 * 678 displays as on 640 * 480 ones. However, if you do use px, you must specify font-size in px, to retain proportionality.

Font properties
Bug 22: doesn't reset line-height to normal

The rule on shorthands in general is that all unspecified values that can be set by that property are set to the initial value. Thus SPAN {font-weight: bold; font: 16px Arial} does not result in bold text, since the initial value of font-weight is normal, and font was set after font-weight thus overriding it. Netscape does get this right for font-* properties, but it doesn't get this right SPAN (or whatever) {line-height: 72px; font: 16px Arial}, failing to override the 72-pixel line-height. This means that you must explicitly line-height to normal when using the font: shorthand (providing that that is the value that you want, of course).

Section F - Text bugs

Bug 1: %

Percentages on text-indent relate, according to the CSS spec, to the width of the containing block. In Netscape they relate to the width of BODY. If the element's width is less than BODY, the indent can cause the first line to be put far to the right of the rest of BODY. This means percentages should be avoided on text-indent.

Bug 2: overline unsupported

Netscape does not support overline.

Bug 3: inherited instead of spanned

The CSS specification states that text-decoration is not inherited, but spans descendant inline elements (meaning, for example, that their color should be that of the parent element), since they are still 'inside' that element. Netscape doesn't apply this, however, but inherits them instead.

This is not very serious, but is a bug nonetheless.

Bug 4: doesn't transform accented characters

Text-transform does not transform accented characters - only basic ASCII ones.

Bug 5: Not inherited

The CSS spec states that text-transform is inherited, but Netscape does not apply this. This means that if you want text-transform to inherit, you will have to add extra selectors. E.g.:

P.transformed {text-transform: uppercase}
P.transformed, P.transformed SPAN, P.transformed EM, etc. for everything inside P.transformed {text-transform: uppercase}

Bug 6: only works on images

Vertical-align only works on images.

Bug 7: super unsupported

Netscape doesn't support vertical-align: super.

Bug 8: sub unsupported

Netscape doesn't support vertical-align: sub.

Bug 9: % and lengths unsupported

Vertical-align: % or <length> is not supported.

Bug 10: middle

Netscape aligns middle by aligning the middle of the image to the baseline of the parent font, not the baseline + half the x-height as it should.

Bug 11: multiple vertically aligned elements on a page

When there is more than one element (i.e., image) that has vertical-align set on it in a page, and there are at least two different values, all the elements are put next to each other at the location of the first image (even if the second and subsequent elements are many hundreds of pages below it), and the vertical alignment is destroyed. As a result, you MUST NOT have more than one vertically aligned image on a page (even baseline, super or sub [although made up values do not trigger this particular bug]).

Bug 12: top

Netscape applies top as text-top, which is wrong, since top depends on line-height but text-top doesn't.

Bug 13: bottom

Netscape applies bottom as text-bottom, which is wrong, since bottom depends on line-height but text-bottom doesn't.

Bug 14: nowrap not supported

Netscape does not support white-space: nowrap.

B Bug 15: normal doesn't work to suppress nowrap attribute

White-space: normal, which should override the HTML nowrap attribute, doesn't do so, having no effect at all on nowrap.

Bug 16: unsupported

Netscape doesn't support letter-spacing.

Bug 17: unsupported

Netscape doesn't support word-spacing.

Section G - color and background bugs

User colors
Bug 1: destroys

Netscape is overly tolerant of invalid colors.

If a color (including background color) has the # before it, it behaves appropriately, ignoring invalid colors.

However, if the # is not included, it treats the number as hexadecimal, except it replaces unknown letters with 0. For example, color: bright becomes color: #b00000.

If the word is 3 letters or shorter, it is padded out, if need be, to be 3 letters long and rendered as such. If it is more than 3 letters long, it is padded out to 6 letters. If it is more than 6 letters long, Netscape's behavior is unpredictable, but it will use zero or more of the valid hexadecimal digits in the word, plus zero or more zeroes in constructing a number.

In addition, if the first 'letter' is a digit, the whole word is ignored.

The result of this is that color: inherit is rendered as color: #00e000, and that the user interface colors are unusable, and, if used, must be hidden from Netscape 4.

Background attachments
Bug 2: unsupported

Netscape does not support background attachments.

Background positions
Bug 3: unsupported

Netscape does not support background positions.

Background colors
Bug 4: applied as if inline

When applied to block elements, it is only applied behind the text and not to the whole block as it should be. This thus does not color in the leading or the end of lines. However, if you set border: none, it is fixed. (Note that this doesn't apply to background-image) E.g.:

P {background-color: red}
P {
background-color: red;
border: none; /* Or any other value */

Bug 5: margins rendered in the color of canvas, not that of ancestor

Netscape incorrectly makes the margins of block elements transparent to BODY, rather than simply transparent to the containing block color. This could result in very unsightly problems, especially since it applies equally with background-image and background-color.

Bug 6: transparent makes element transparent to canvas, not ancestor

Netscape causes background-color: transparent to make the element transparent to BODY rather than simply transparent to the containing block color. Note that this means that background-color: transparent, which should, as the initial value, have no effect is therefore different from the default behavior.

Background images
Bug 7: margins rendered in the color of canvas, not that of ancestor

Netscape incorrectly makes the margins of block elements transparent to the canvas color, rather than simply transparent to the containing block color. This could result in very unsightly problems, especially since it applies equally with background-image and background-color.

Bug 8: url()

The CSS spec defines the URI token as the literal string url(, followed by any amount of whitespace (including tabs, line feeds, etc.), followed by a string, followed by any amount of whitespace, followed by a ). Netscape, on the other hand, doesn't allow the white space before to contain line feeds, form feeds or carriage returns. As a result, you may need to change some of your background declarations (also applies to background):

BODY {background-image: url(
BODY {background-image: url(back.jpg

Bug 9: background attribute on BODY, on TABLE elements, etc. vs. none on style sheet

The background attribute on BODY is applied over background-image: none, though bgcolor and background-color, etc., work fine. Thus:

BODY {background-image: none}
<BODY background="back.jpg">

Back.jpg will be applied here. But:

BODY {background-image: url(madeupname)}
<BODY background="back.jpg">

This would be applied correctly, so if you want to use style sheets to override HTML backgrounds, you must use this technique. (Note that this bug is not non-support of background-image: none, since BODY {background-image: url(back.jpg); background-image: none;} works fine.)

Bug 10: missing background images result in a square of black

If you specify a background image that is not available, Netscape renders it as a square of black on top of the text, thereby ruining the element. It is therefore important to ensure that your images are always available.

Bug 11: URIs taken relative to HTML file

Linked style sheets' base directory is interpreted as being the HTML file, not the style sheet. This means that if you use a background image in a linked style sheet you should include an absolute URI, or keep the style sheet in the same directory as the HTML (otherwise the image won't be found).

Bug 12: sets background-color to black

Using the background: shortcut has the effect of setting background color to black, unless a different color is specified. For example: BODY {background-color: red; background: url(back.jpg)} sets the background color to black.

This is very serious if you specify a background image that is unavailable, if the user is browsing off-line, with a background-repeat other than repeat, while the page is loading or if your background is partially transparent.

This means that if using background: to specify a background image, you should always specify a background color as well. E.g., background: blue url(back.jpg).

Note that transparent will not work to suppress this bug - you must use a specific color.

Next section

Because this document is very long, it has been split into two parts to reduce download times. To continue to the next section, which considers margins, borders, tables, lists, floats, forms and more, click here.