|
|||||||
|
|||||||
|
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 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.
The bugs here are so many, so serious, and so unpredictable that you should not use Netscape for anything more complicated than simple text layout - e.g., margins on P, H1, etc. Borders are also only usable to do something basic, like giving P a border.
Here is an example, taken from the RichInStyle.com frontpage, of the most complicated sort of thing you should attempt:
H1.main {
border: 40px;
border-color: #f00;
border-style: ridge;
color: black;
background: #fc0;
margin-top: 0; /* I normally have quite large margins on H1 */
margin-left: 0; /* To prevent my usual negative margin */
font-size: 60px; /* N.B. I do not declare line-height on H1 (so the initial value, normal, will
work fine), but if you do, there are dozens of bugs to bear in mind */
font-family: "Comic Sans MS", sans-serif;
text-align: center}
<h1 class="main">
RichInStyle.com
</h1>
Margins and padding don't work on images.
BODY is automatically given a small margin that cannot be removed.
Margins and padding are calculated relative to the width of the viewport, rather than relative to the containing block width. Due to the previous bug, this means that 50% is slightly more than half of BODY's width. Thus, for example:
BODY {margin: 20%;
padding: 0}
DIV.a {float: left;
margin-right: 50%}
DIV.b {
margin-left: 50%}
Would result in a margin-right of 20% + 50% of viewport ≅ 70%, thus giving DIV.a (and DIV.b) width ≅ 30%.
Even worse is the fact that something like this will cause havoc:
DIV.container {
width: 200px
}
DIV.child {
margin-left: 80%
}
This means that you may wish to use browser detection to detect Netscape, or avoid % on margin and padding when the size of the margin is critical..
Setting margin-top in cm, mm, pt, pc or in on any element whatsoever can result in 10 or more blank (save page numbers, times, document locations, etc.) pages when printing.
To avoid this, you must use px, em, % or ex (or thin, thick or medium, in the case of border) if your page's nature is such that it might be printed. However, em and ex are buggy, 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. If you are wondering whether to use %, recall that this relates to the width of the containing block on the box model properties, so this is a useful thing to use.
Setting H1 {margin: 0; padding: 0}, which should result in no space around H1, doesn't work - it can only be reduced by the unsafe method (requiring browser detection) of negative margins. The affected elements are:
Margin-top doesn't work on inline elements.
You can't set margin-bottom to a negative value.
Margin-bottom set on inline elements will be applied to the containing block rather than to the element itself.
Setting any of these properties in cm, mm, pt, pc or in on any element whatsoever can result in 10 or more blank (save page numbers, times, document locations, etc.) pages when printing.
To avoid this, you must use px, em, % or ex (or thin, thick or medium, in the case of border) if your page's nature is such that it might be printed. However, em and ex are buggy (so is % on line-height), 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. If you are wondering whether to use %, recall that this relates to the width of the containing block on the box model properties, so this is a useful thing to use.
Although Netscape correctly handles the situation where both the margin-top and margin-bottom are positive, it fails to handle negative margins correctly, adding the two together where both are negative instead of applying the most negative of the two as the CSS spec states.
Netscape fails to collapse adjoining margin-tops or margin-bottoms, only collapsing between a margin-top and margin-bottom. This will result in excessive space between such margins.
Margin-left on OL, UL and BLOCKQUOTE and margin-right on BLOCKQUOTE are interpreted relative to the element default, rather than to the left of the containing block. This means that you should either avoid setting margin-left and margin-right on these elements, or use browser detection and deduct the appropriate amount for Netscape.
Setting either of these results in the element being thrown that far in the direction specified, and overlapping thus results. The margin is interpreted as position: relative with an offset equal to the margin specified. Thus avoid like the plague.
Auto is interpreted as 0.
Margin-right cannot be set to a negative value.
Netscape cannot parse to save its life, and as a result it interprets border-style: hidden as outset.
The dotted border style is applied as solid.
The dashed border style is applied as solid.
Although the CSS specification permits up to four styles on border-style, Netscape only uses the first one.
Although double borders should result in a border whose total width, including space between borders is equal to border-width, the total width in Netscape will instead be three times border width.
The CSS spec states that up to four colors can be specified for border-color, but Netscape only applies the first one.
Border-color's initial value is the element color. Netscape ignores this and always applies black. If background-color: black, this will make the border invisible, so you should always set border-color.
Some elements with borders are given a small amount of padding inside the border. This is given the color of the parent element. This 'pseudo-padding' cannot be suppressed.
Backgrounds are not applied to the 'pseudo-padding' (see also above). The means you can't apply backgrounds to empty boxes.
Setting border-style to solid should result in a medium sized border, since medium is the initial value of border-width. In Netscape this is not the case. Thus instead of the initial values being border-style: none, border-width: medium, the initial values are border-style: solid, border-width: 0. This is easy to correct, however, simply by always setting both border-style and border-width.
Setting any border properties in cm, mm, pt, pc or in on any element whatsoever can result in 10 or more blank (save page numbers, times, document locations, etc.) pages when printing.
To avoid this, you must use px, em, %, ex, thin, thick or medium if your page's nature is such that it might be printed. However, em and ex are buggy, so you might only wish to use px. This is not as bad a 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. If you are wondering whether to use %, recall that this relates to the width of the containing block on the box model properties, so this is a useful thing to use.
Where BODY is given a border, it is only drawn around the whole of its content rather than BODY itself. E.g.:
BODY {border: solid thin}
P {width: 200px}
/* BODY's border would be 200px wide! (instead of going across the whole screen) */
If background-color is explicitly set to transparent on elements with borders, the element is given a black background color. So don't do it.
Setting borders on inline elements results in a line break before and after the element, thus rendering them unusable. Note that this even includes specifying border: none.
Setting a border on an image results in the image being displaced, a border being drawn around empty space, and thus generally making borders unusable. Note that this even includes specifying border: none.
Giving PRE a border stops it being a preformatted element, unless you add white-space:
pre.
Setting white-space: pre results in the suppression of borders elements with
white-space: pre, EXCEPT PRE with white-space explicitly set to pre, thus meaning that on other
elements you have a choice between the preformatting and the border.
Under certain circumstances, elements with borders inside lists will behave like TABLEs and not inherit style. To see an example of this, click here. This means that I would reiterate my advice above that you add every block element (inline elements do not need it because of inheritance from their blocks (providing you keep all inline elements inside block elements)) to the BODY selector, as with the example above. E.g.:
BODY, ADDRESS, P, DIV, TD, TH, H1, H2, H3, H4, H5, H6, SPAN {
/*
all the properties you want to inherit from BODY go here.
Note this should be the first line of the style sheet, so that subsequent declarations can
override it.
*/
}
Netscape relates border widths in percentages (a vital extension to CSS) to the width of the viewport rather than that of the containing block.
If you have successive unclosed P elements with borders, the browser will crash; for example, <P style="border: solid medium"><P style="border: solid medium"> will crash the browser.
Netscape doesn't support the border-left shorthand.
Netscape doesn't support the border-right shorthand.
Netscape doesn't support the border-top shorthand.
Netscape doesn't support the border-bottom shorthand.
Netscape doesn't support height.
Setting this property in cm, mm, pt, pc or in on any element whatsoever can result in 10 or more blank (save page numbers, times, document locations, etc.) pages when printing.
To avoid this, you must use px, em, % or ex (or thin, thick or medium, in the case of border) if your page's nature is such that it might be printed. However, em and ex are buggy (so is % on line-height), 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. If you are wondering whether to use %, recall that this relates to the width of the containing block on the box model properties, so this is a useful thing to use.
% on width should relate to the width of the containing block. In Netscape 4, however, they relate to something else, which seems to be the length of a piece string. This makes % unusable (without specific testing in Netscape). However:
BODY {
width: 90%;
}
/* According to the CSS spec this would result in a margin-left of 0 and a margin-right of 10%. So
change it to: */
BODY {
margin-left: 0;
margin-right: 10%
}
/* Which _will_ work, implying the required width. This is so for all elements. */
Width doesn't work on replaced elements.
It is not possible to use width to make an element go outside its containing block if that block has a border. This wouldn't work:
DIV {
width: 200px;
border: solid thin;
}
P {
width: 400px;
}
<DIV>
<P>
</P>
</DIV>
Nor is it possible to use margin-right to make it work, since Netscape doesn't support negative margin-right.
It is not possible to use width to make elements (including BODY) exceed the width of the viewport.
Where a relatively positioned element has block level child elements, it causes an unsightly increase to margin-bottom, unless the closing tag is omitted. E.g.:
DIV.x { position: relative; }
<DIV class="x">
<P>
Hello
</P>
</DIV>
This would cause an extra margin-bottom (as would any child block level element), unless the closing tag is omitted. However, of block elements it is only possible to omit P's closing tag.
If you position A absolutely , it is literally impossible to click on it, thus A should not be absolutely positioned.
Borders only work on absolutely positioned elements when the element is at least one line long.
Only the space behind the text is given a background-color (b-image works fine) on absolutely positioned elements. To fix this, add the Netscape specific layer-background-color property, which should be set to the same value.
% on top are interpreted as relative to the height of the viewport on absolutely positioned elements, not the height of the root element as they should be.
Nested elements with display: block crash some versions of Netscape, and as such, doing this should be avoided.
Netscape only creates line breaks before display: block elements, not after, so, e.g.,:
<div>
the cat
<span style="display: block">
sat
</span>
on the mat.
<span style="display: block">
and the dog </div>
Would be rendered as:
the cat
sat on the mat
and the dog
Instead of
the cat
sat
on the mat
and the dog
If used on elements other than P, such as DIV, overlapping is likely to occur.
This doesn't work unless the element's closing tag is omitted - a closing tag causes the line break.
Overflow: scroll is rendered as overflow: hidden, which is very bad.
Clip is buggy, and is to be avoided without prior testing.
Z-index doesn't work on images, only on text.
The following two pieces of code are equivalent:
<P>
<SPAN style="float: left; width: 1em">P</SPAN>arrot.
</P>
<P>
arrot.<SPAN style="float: left; width: 1em">P</SPAN>
</P>
Netscape on the other hand moves floating inline elements that are not the first thing on their lines down to the next line (which may well not exist, thus causing an undesired line feed). This makes float unusable for letters that are not the first thing on their line (the same thing applies for float: right as float: left, which is rather inconvenient, since this is the logical place to put right floated inline elements).
Width is not honored on floating inline elements, instead Netscape prefers to allocate the width that the content requires.
Floats won't float out of their containing block. For example, if you float an image, rather than being taken out of normal flow and therefore being allowed to continue out of its block, it will cause the containing block to be extended so that it fits within it.
If you try float: left on inline text (e.g., drop caps), you will find that the box that the letter sits in (unalterable) is so big and thus ugly as to be unusable. This means I would avoid using float on inline text.
According to the CSS specification, the top of a floating box should be aligned with the top of
the line. This makes <P><SPAN style="float:
left">H</SPAN>ello</P> indistinguishable from
<P>Hello</P>. Netscape fails to do this, aligning the middles of the respective
boxes, which, combined with its bug of increasing the size of floating boxes makes float useless on
inline text.
Try this:
<P>
<SPAN style="float: left; line-height: 1in">H</SPAN>ello hello hello hello
hello hello hello hello hello hello hello hello hello hello hello hello hello hello hello hello
hello hello hello hello hello hello hello hello hello hello hello hello hello hello hello hello
hello hello hello hello hello hello hello hello hello hello.
This should result in a one inch high 'H' block, the top of which is aligned with the top of the rest of the line. What it does instead is apply the inch of line-height to the top of the block as a margin-top. Equally, line-height: 0 sets margin-top: 0, though not overriding any margin-top on P (i.e. line-height: 0 only sets margin-top: 0 if margin-top is not set). Thus line-height should be avoided on floating text.
If you set margins on floating text, it is applied to the containing block rather than to the float itself. This makes margin useless on floating text.
Under certain (unknown) circumstances, properties will 'inherit' from the drop cap to the block. This tends to ruin the page.
If you float something from a line box, if is not the first thing in its line box, it will be moved down to the next line down.
Netscape does not let text-align work on inline floats. For example, <SPAN style="float: right; text-align: right; width: 4em">, which uses the text-align to counteract the effect of the width (required by the specification (and advisable to set too large)), would not take into account the text-align: right (valid on).
Most people will be surprised to find that is possible to get float to work almost perfectly on block elements - 99% of all the bugs are actually caused by the bug with % on width.
DIV.a {
float: left;
margin-left: 0;
margin-right: 50%;
}
DIV.b {
margin-left: 50%;
margin-right: 0;
}
/* This works! E.g.:
<DIV class="a">
Hello
</DIV>
<DIV class="b">
Hello
</DIV>
*/
/* Note that this will not work in compliant CSS UAs, so you will have to use browser
detection */
Where a floating element is placed next to another left floating one, the result is an
unreversable negative left margin on the right floated element. This causes unreadable pages as a
result of the overlap. Thus if you added float: right (or float: left) to DIV.b,
above, this would be the result.
This prevents more than two columns being used.
The best you can do is this:
DIV.a {float: left;
margin-left: 0;
margin-right: 50%;
}
DIV.b {margin-left: 50%;
margin-right: 50%}
<DIV class="a">
Some identical text that is long enough to fill the line.
</DIV>
<DIV class="b">
Some identical text that is long enough to fill the line.
</DIV>
You will find that the vertical alignment is slightly wrong. This will not cause major problems, but you should test before attempting to use float.
E.g.:
DIV.a { float: left;
margin-left: 0;
margin-right: 50%}
DIV.b {
/*
Should float to the right of it, but instead overlaps it.
This means that you must include margin-left and right relative to the left and right of the
containing block, as in my example above. It also makes negative margins
unusable.
*/
}
Alternatively, you could specify the width in pixels/cm/in/mm. This will work. E.g.:
DIV.a {float: left;
width: 350px}
DIV.b {width: 350px}
If set on elements going round a right floating element, it causes the font-size to be such as to make the element the same size as the right floating element. E.g.:
DIV.left {font-size: larger; /* Won't work - is interpreted as the font needed
to make height the same as DIV.right */
font-size: 16pt; /* _Will_ work, as would the total omission of font-size or font-size: smaller
*/
/* width: 67%; */
margin-right: 33%}
DIV.right {padding: 2%;
margin: 2%;
margin-left: 69%; /* width of left of 67 + 2 for margin-left of this one */
float: right;
/* width: 25%; */}
with
<DIV class="right">
</DIV>
<DIV class="left">
</DIV>
If you changed the above code to
DIV.left {float: left;
font-size: anyvalue; /* Will be ignored */
font-size: 16pt; /* _Will_ work, as would the total omission of font-size or font-size: smaller
*/
margin-right: 33%}
DIV.right {padding: 2%;
margin: 2%;
margin-left: 69%; /* width of left of 67 + 2 for margin-left of this one */ /*
width: 25%; */} <DIV class="left">
</DIV>
<DIV class="right">
</DIV>
Font-size won't work on floating block elements at all.
Where the two widths (as in DIV.a and DIV.b) exceed the viewport width, the bottom (not the right!) of the left element is cut off. This makes the use of pixels and lengths impracticable, since it is not possible to predict the viewport width.
Where an element is to the right a float, its first line might overlap slightly. As a result, you may wish to add a little padding, or a few non breaking spaces to the first line of the element. E.g.:
<DIV class="leftfloat">
</DIV>
<DIV class="nexttoit">
</DIV>
If you set clear and float on the same element, then a crash will result in Mac Netscape.
Netscape floats its marker box relative to the left of its content, not the left of the element.
Where non-floated elements overlap with floated ones, rather than simply overlapping, they cause the shape of the block element to be affected. For example:
<DIV style="float: left; width: 20%; line-height: 20px; font-size: 16px; background: red"> A run-in heading </div> <DIV style="background: blue; line-height: 20px; font-size: 16px"> And some text, which will flow around it in a pleasing way. Isn't that wonderful? And some text, which will flow around it in a pleasing way. Isn't that wonderful? And some text, which will flow around it in a pleasing way. Isn't that wonderful? </div>
This would cause the following rendering:
| A run-in heading | And some text, which will flow around it in a pleasing way. Isn't that |
| wonderful? And some text, which will flow around it in a pleasing way. Isn't that wonderful? And some text, which | |
| will flow around it in a pleasing way. Isn't that wonderful? | |
Rather than this correct one:
| A run-in heading | And some text, which will flow around it in a pleasing way. Isn't that |
| wonderful? And some text, which will flow around it in a pleasing way. Isn't that wonderful? And some text, which will flow around it in a pleasing way. Isn't that wonderful? | |
Although horizontal rules, as borders, should overlap with floats, Netscape shortens them to stop this happening.
Clear does not work properly - sometimes it moves the element down and to the right, at others just down.
I have stated that width: % is generally buggy, and indeed this is true with float. If you use width in % on float, the page will be an unreadable mess.
In addition, note that where you specify a margin-left or margin-right in Netscape, Netscape places the element that far from the left of the BODY. This means that you should use padding instead of margin, unless you intend to use the margin to simulate width.
You cannot have negative margin-right and margin bottom in Netscape 4. This is significant because of the width bug.
Style does not ever, under any circumstances, inherit into TD and TH.
The styles that are affected are all those that are inherited, including: the font properties, color:, line-height, text-align.
The way to fix this is to take the BODY declaration and separate it into inherited and non-inherited styles. For example:
BODY {margin: 5%;
line-height: 20px;
color: green;
padding: 5%;
background: red url(back.jpg);
font: 16px Verdana, sans-serif}
Becomes:
BODY {margin: 5%;
padding: 5%;
background: red url(back.jpg)}
BODY {line-height: 20px;
font: 16px Verdana, sans-serif;
color: green}
Next, add TD and TH to the inherited BODY declaration.
BODY, TD, TH {line-height: 20px
font: 16px Verdana, sans-serif;
color: green}
Follow this procedure for ALL declarations for elements that contain or might contain TABLEs.
E.g.:
BODY.class {color: blue}
Becomes:
BODY.class, TD, TH {color: blue}
DIV, OL, UL {line-height: 20px}
Becomes (because DIV/OL/UL might contain TABLEs):
DIV TD, DIV TH, OL TD, UL TD, OL TH, UL TH {line-height: 20px}
Where a TABLE with its HTML border="0" is inside an element with a border, it automatically has its own border set.
When a TABLE is set by any method to have a background color, and TD or TH have a font-family declaration that is precisely the same as that of BODY (as they will do if you use the method above and you set font-family), TD may be given BODY's background color if BODY's is #000000 instead of TABLE's. E.g.:
BODY, TD, TH {font-family: Arial}
Or
BODY {font-family: Arial}
TD {font-family: Arial}
With
BODY {background-color: #000000}
TABLE {background-color: y}
There are two solutions:
BODY {background-color: #010000} /* Unnoticeable amount */
Or
TD {font-family: madeup, "Actual Font"}
/* Where Actual Font is the one you really want */
Note that this bug is very rare.
Borders can't be applied to TABLEs.
After TD and TH elements, some of the time, all inherited properties are lost. This means that you must add every single block tag to the TD, TH and BODY above. In addition, where a TABLE is in a LI (or any situation where TABLE is not followed by a block level tag), because of the bug whereby properties applied to LI, DD and DT are applied only to the marker and not to the content, this won't work. Thus I would recommend that you follow every TABLE with a SPAN or a block element, and add this to the selector. E.g.:
BODY, DIV, TD, TH, P, OL, UL, DL, DD, DT, H1, H2, H3, BLOCKQUOTE, H4, H5, H6,
ADDRESS, SPAN {
all inherited properties go here
}
Padding is applied to TD and TH as well as to TABLE. This means you should not apply padding to TABLE, although applying it to TD and TH works fine.
Padding is completely broken on TR, TD and TH and should not be used.
Contextual selectors do not work if they include TABLE or TR or refer to a TABLE or TR; for example, TABLE TD won't work.
Netscape does not support background images on tables or table rows.
If you do not close the last TR in a TABLE, it will inherit the table's margin into the rest of the document.
Netscape allows text-align to affect the position TABLEs. This is wrong because TABLEs are block boxes, and text-align only affects inline content.
Netscape doesn't let width work on table elements.
If you position tables, or elements that contain them, a crash will result in earlier versions of Netscape (I have experienced it in 4.04).
If you enclose FORM elements in P, each /p will be interpret as /container. E.g.,:
<form>
<p>
<input type="text"> <!-- or any other form element -->
</p> <!-- /container = /form -->
<p>
<input type="text"> <!-- or any other form element -->
</p> <!-- /container = /body -->
</form>
The consequences of this are very serious; for example, if you close the FORM then the form controls won't work properly (e.g., they won't be sent to your form processor); if you close the BODY then the margins and any other properties of the BODY will be lost.
As a result, you should either use DIV, or omit the end /p.
The background-color bug (i.e., only coloring behind the text) applies to FORM, but the border: none workaround also works.
Netscape applies backgrounds on INPUT type="radio" in a mildy glitchy way, coloring the square that the button is circumscribed within, but not the button itself.
The only styles that are applied to form elements are font-size, font-style, font-weight, font-family, text-decoration margin and padding [margin and padding are buggy on inline elements anyway - see above, so therefore are completely broken on forms as well] properties - not color or background.
Note that when I refer to form elements, I mean all form elements except for FORM itself - FORM {background-image: whatever} works, but INPUT {background-image: whatever} does not.
Line-height transforms SELECT and OPTION into block elements.
These are badly bugged, being drawn on the line below the element.
These are badly bugged, destroying the TEXTAREA so that it is no longer a TEXTAREA (i.e., can't be typed in).
These are badly bugged, destroying the SELECT/OPTION and displaying garbage.
These don't work unless the TEXTAREA or OPTION (NB not SELECT) is enclosed in a SPAN (or DIV if you want a block element) and the style applied to that.
White-space: normal doesn't work on TEXTAREA.
Text-align doesn't work to move the contents of TEXTAREA.
If you allow line-height to inherit into form elements, you will experience problems with overlapping elements. The problems are only midly annoying on buttons or text fields created by the INPUT element, but very serious on TEXTAREA, which will be destroyed if you allow line-height to inherit into it.
Apart from not specifying line-height at all, a useful workaround is to specify line-height: normal on elements that contain form controls. For example, this is the code used on RichInStyle.com's front page to prevent this:
<DIV style="line-height/* */ : normal"> <TEXTAREA cols=50 rows=30> </DIV>
Note, incidentally, the /* */ after the line-height. This hides the declaration from Microsoft Internet Explorer, which, in version 3, will treat that declaration as line-height: 0, and means that other versions aren't forced not to use the line-height.
This works fine.
If you set properties on LI, DD, DT, as in LI {font-family: Arial} or UL LI {color: blue} they are only applied to the marker, and not the content. DD and DT don't have markers, but are treated in the same way, so there is no effect at all.
This means you should declare on OL, DL and UL instead, and rely on inheritance.
The only thing that this bug prevents is the application of different styles to DD and DT.
Where font-size is applied to LI, and hence the list item marker is made larger (N.B., not the text - see the bug above, the marker-offset is not increased. As a result, if the font-size is big enough, overlapping will result.
These are buggily applied as padding-top (if padding-top worked) instead, making them unusable.
Note that these wouldn't work anyway, due to the bug whereby style is applied to the marker and not the content, but this bug is included in case you use the same style sheet for Netscape and other browsers.
These should be avoided like the plague, because what they do is have a border round a single empty space, followed by a <BR> before the element content with the whole thing misaligned with the list marker.
Note that these wouldn't work anyway, due to the bug whereby style is applied to the marker and not the content, but this bug is included in case you use the same style sheet for Netscape and other browsers.
Where line-height is applied to LI (note that this wouldn't work any way - see above), the whole line-height is applied to the top of the OL/UL, and not to the LI. Thus you must not use line-height on LI. However:
LI {line-height: 18pt}
Is equivalent to (because of inheritance):
OL, UL {line-height: 18pt}
Thus all you need to do is change LI line-height declarations to OL and UL ones!
Margin-top and padding-top are buggily added to the OL/UL/DL margin-top rather than to the LI/DT itself, thus making margin-top and margin-top unusable on LI, and DT. Thus:
OL {margin-top: 1in}
LI {margin-top: 1in}
/* OL would have a 2 inch margin-top, and LI none at all */
Note that these wouldn't work anyway, due to the bug whereby style is applied to the marker and not the content, but this bug is included in case you use the same style sheet for Netscape and other browsers.
Margin-bottom and padding-bottom are buggily applied to the content but not the marker. This causes the marker and content not to be lined up. Thus margin-top and margin-bottom are both unusable and should be avoided at all costs on LI.
Note that these wouldn't work anyway, due to the bug whereby style is applied to the marker and not the content, but this bug is included in case you use the same style sheet for Netscape and other browsers.
If you set padding-left, margin-left, margin-right or padding-right on LI, the list item is suppressed. This makes them unusable.
Note that these wouldn't work anyway, due to the bug whereby style is applied to the marker and not the content, but this bug is included in case you use the same style sheet for Netscape and other browsers.
These are buggily not applied to the first DT in a DL, making them unusable.
Note that these wouldn't work anyway, due to the bug whereby style is applied to the marker and not the content, but this bug is included in case you use the same style sheet for Netscape and other browsers.
Setting these doesn't work, and results in margin-left: 0; padding-left: 0.
Note that these wouldn't work anyway, due to the bug whereby style is applied to the marker and not the content, but this bug is included in case you use the same style sheet for Netscape and other browsers.
Netscape allows text-align to affect the position of list markers. This is wrong because list markers are positioned relative to the border edge of the element, and the border edge's position isn't affected by text-align.
Netscape allows text-indent to affect the position of list markers. This is wrong because list markers are positioned relative to the border edge of the element, and the border edge's position isn't affected by text-indent.
Display: list-item is interpreted as display: block, margin-left: (OL's margin) but no list-items are drawn
If list-style-type is set to none on OL or UL, and either margin or padding or both is also set, the list-style-type is set to disc (even on OL). This does not apply to LI, because their bugs override OL's/UL's.
The marker glyphs on these list-style-types are followed by '.', which is wrong according to the CSS specification.
If a LI is part of an unordered list, the lower-roman, upper-roman, decimal, lower-alpha and upper-alpha list-style types result in list-style-type: circle.
If a LI is part of an ordered list, the square, circle and disc list-style types result in list-style-type: decimal.
List-style-position doesn't work.
List-style-position doesn't work.
There is no way to change the color of HR.
Setting a border on HR screws it up, drawing a tiny box above and below the rule rather than doing what it should do, which is to draw a border round the rule.
Netscape allows horizontal padding to affect HR, which is wrong because HR is a border and padding is applied inside the border.
Vertical padding on HR, which should be applied inside the HR, is instead applied as a vertical margin outside the HR.
Netscape allows text-align to affect the alignment of HR. This is wrong because it should have no effect - text-align only affects inline content - not borders.
Larger and smaller on font-size are applied as 1.6* as large.
This is not a bug, but CSS 2 (though not CSS 1) allows an element to have more than one class, as in class="class1 class2". Netscape ignores entirely all such elements. If you have <ELEMENT class="class1" class="class2">, then Netscape deems the element only to have class2.
CSS 2 also allows elements to be :link/:visited as well as :active (e.g., A:active:link). Netscape will ignore all such declarations.
Copyright © RichInStyle.com 2000; all rights reserved. See copyright document for terms of use. Please visit Bukit Lawang flood appeal.