|
|||||||
|
|||||||
|
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.
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).
Section E - Font bugs (22 bugs).
Section F - Text bugs (17 bugs).
Section G - Color and background bugs (12 bugs).
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).
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)
Total bugs = 30 + 2 + 22 + 17 + 12 + 15 + 24 + 18 + 21 + 13 + 10 + 19 + 5 + 42 = 250.
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.
When the media attribute specifies a comma separated list of style sheets (e.g., media="screen, print") Netscape will ignore the style sheet.
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.
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.
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.
Netscape depends on Javascript to render style sheets, so if you disable style sheets, it will also disable style.
If an external CSS file is missing, the page will not be rendered.
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 */
</STYLE>
<LINK rel="stylesheet" type="text/css" href="name.css">
This becomes:
<LINK rel="stylesheet" type="text/css" href="name.css">
<STYLE type="text/css">
</STYLE>
Netscape does not provide any means to select alternate style sheets.
Netscape does not support @import.
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 */
#id
/* Is applied over */
A /* without id or class */
:visited is not applied to local hrefs (e.g., <A href="#"), but :link is instead (always).
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>).
Netscape fails to distinguish between A:link and :link for specificity. Neither does it distinguish between A:visited and :visited.
Netscape does not support :active.
Netscape does not support :first-line.
Netscape does not support :first-letter.
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.
Style is not applied to the HTML element. However, it is simple matter to change HTML {} into BODY {}.
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.
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.
IDs are treated as case-insensitive, but the HTML specification states that they are case-sensitive.
Classes are treated as case-insensitive, but the HTML specification states that they are case-sensitive.
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).
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:
<BODY>
<NOSCRIPT>
</NOSCRIPT>
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,
<BODY>
<P>
<NOSCRIPT>
</NOSCRIPT>
</P>
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:
<BODY>
<P>
<NOSCRIPT>
</NOSCRIPT>
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:
<BODY>
<NOSCRIPT>
</NOSCRIPT>
<DIV class="body"> /* And add .body to the BODY selector */
</DIV>
</BODY>
Or: (better IMHO)
<BODY>
<DIV>
<NOSCRIPT>
</NOSCRIPT>
...
</DIV>
</BODY>
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.:
BODY {
background: red;
}
P, DIV, ADDRESS, OL, UL, DL {
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.:
<BODY>
<NOSCRIPT>
Noscript content here
</NOSCRIPT>
<H1>
A heading here
</H1>
Some text
<P>
New paragraph
<P>
New paragraph
This is wrong - 'Some text' is not enclosed in an element, and thus will not have any style applied to it.
<BODY>
<NOSCRIPT>
Noscript content here
</NOSCRIPT>
<H1>
A heading here
</H1>
<P>
Some text
</P>
<P>
New paragraph
</P>
<P>
New paragraph
</P>
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.
Netscape does not weight sort.
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.
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.
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.
Netscape does not support comments between : and IDENT on pseudo-classes; for example, A:/* */link, would be ignored in Netscape.
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:
<body>
<div class="parent">
<div class="a">
Hello
</div>
<div class="b">
Hello
</div>
<div class="c">
Hello
</div>
</div>
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.
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:
<BODY>
<DIV class="a">
/*
This one has no font-size that applies to it.
*/
Hello
</DIV>
<DIV class="b">
Hello
</DIV>
<DIV class="c">
Hello
</DIV>
<DIV class="d">
Hello
</DIV>
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.
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}
Etc.
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.
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;
}
<BODY>
<DIV>
<P>
Hello
</P>
</DIV>
</BODY>
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):
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.
Adjacent font-sizes (e.g., 15 and 16px, 13 and 14px) are applied as the same
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.
Netscape renders xx-small illegibly. Whilst this is not a bug, and I have not listed as such, it is worth bearing in mind.
Netscape destroys font-style: oblique, rendering it as italic.
Netscape doesn't support the lighter value.
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.
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.
Netscape does not support font variants.
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).
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 ", or C), 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.
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).
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.
Line-height doesn't work on inline elements.
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;
}
<BODY>
<DIV>
<P>
Hello
</P>
</DIV>
</BODY>
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):
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}
<DIV>
<P>
</P>
</DIV>
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.
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}
Becomes:
DIV.box {
line-height: 120px;
border: solid thin;
margin-left: whatever}
Or:
DIV.box {
line-height: 120px;
border: solid thin;
margin: whatever} /* including 0 */
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.
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}
<P>
<SPAN style="font-size: 72px; line-height: 78px; color: red">T</SPAN>he first sentence
is here.
</P>
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.
</P>
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}
<P>
<IMG width="" height="">
</P>
/* Would work if P's line-height were omitted, or if you had P.containsimage {line-height: normal}
*/
Some versions of Netscape 4.0* apply all the line height below the line
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.
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.
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).
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.
Netscape does not support overline.
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.
Text-transform does not transform accented characters - only basic ASCII ones.
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}
becomes:
P.transformed, P.transformed SPAN, P.transformed EM, etc. for everything inside P.transformed
{text-transform: uppercase}
Vertical-align only works on images.
Netscape doesn't support vertical-align: super.
Netscape doesn't support vertical-align: sub.
Vertical-align: % or <length> is not supported.
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.
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]).
Netscape applies top as text-top, which is wrong, since top depends on line-height but text-top doesn't.
Netscape applies bottom as text-bottom, which is wrong, since bottom depends on line-height but text-bottom doesn't.
Netscape does not support white-space: nowrap.
White-space: normal, which should override the HTML nowrap attribute, doesn't do so, having no effect at all on nowrap.
Netscape doesn't support letter-spacing.
Netscape doesn't support word-spacing.
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.
Netscape does not support background attachments.
Netscape does not support background positions.
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}
Becomes:
P {
background-color: red;
border: none; /* Or any other value */
}
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.
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.
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.
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(
back.jpg
)}
Becomes:
BODY {background-image: url(back.jpg
)}
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.)
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.
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).
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.
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.
Copyright © RichInStyle.com 2000; all rights reserved. See copyright document for terms of use. Please visit Bukit Lawang flood appeal.