WHY DOES .CLASS_NAME NOT WORK IN NETSCAPE?
You have been betrayed not by Netscape, but by Microsoft. Underscores in class/id selectors are invalid CSS syntax, and CSS requires that the entire rule containing these "unknown" characters be ignored. Netscape has *gasp* actually implemented CSS-1 more correctly than IE here. IE silently forgives your error, teaching you bad habits and making you mad at Netscape and other parties (such as Opera) who support the standard.
The reason for no underscores: forward-compatible parsing: http://www.w3.org/TR/REC-CSS1#forward-compatible-parsing. CSS-1 begat CSS-2, and CSS-3 is in the works. New versions of the language bring new features, and these must have unique syntaxes. To keep from running out of syntactic "space" prematurely, the kinds of characters allowed in each selector, property, or value must be carefully scoped. MS has already hosed its chances to implement some powerful CSS-2 and 3 stuff because shipping product interprets this new stuff, erroneously, as CSS-1.
UPDATE The underscore has been added to the CSS2 identifier productions ex post facto update to spec. How could such an omission pass without notice for so long if something else were intended? Now, three years after CSS2 reached final publication status, we have a change in a key part of the grammar that will affect thousands of style sheets. The new grammar is better, but why change now?
In one simple blow it advanced the compatibility rate of MSIE and reduced the same rate for all other browsers that used to be CSS compatible in this area.
EASY WAY TO GET LINKED SHEETS FOR IE AND NETSCAPE
<head>
<link disabled rel=stylesheet href="myNetscape.css" type="text/css">
<script language="JScript"><!--
if(document.all)document.createStyleSheet("myIE.css")// -->
</script>
</head>
That's all you need! - IE4+, but not Netscape, will completely ignore the <link> tag above because it contains the "disabled" attribute, which only IE recognizes.
Netscape won't read anything within the <Script> tag with "JScript" stated as the script language. But IE will. The (document.all)? condition is within the JScript only to prevent IE3 from loading a stylesheet not intended for it.
COMMENTS ON TABLE CELLSPACING
From Newsgroup: comp.infosystems.www.authoring.stylesheets
Question: How can I do the equivalent of <table cellspacing="0" cellpadding="0" border="0">
Answer: For cellpadding, simply use the 'padding' property of the table cells.
CSS2 specifies two models for table cell borders [1]:
1. In the separated borders model - 'table{border-collapse:separate;}' - each cell has it's own border, and the space between the borders (cellspacing) is specified using the 'border-spacing' property [2].
2. The collapsed borders model - 'table{border-collapse:collapse;}' - collapses the borders on each cell into a single border between the cells, so there is no such thing as cellspacing at all, and the 'border-spacing' property is ignored. According to CSS2 this should be the default.
IE5: defaults to the 'separated borders model', but doesn't understand 'border-spacing', so some fixed amount of cellspacing is always present. This can be got rid of by using the 'collapsed borders model' instead.
Mozilla: hasn't quite implemented the collapsed borders model yet, so it defaults to the saparated borders model, but 'border-spacing:0;' will get rid of the cellspacing.
Opera5: implements both models, and 'border-spacing' correctly.
So something like the following would do:
table {
border-collapse:collapse;
border-spacing:0;
}
td {
padding:0;
border:0 none;
}
Question: with CSS so Mozilla does display images in a table without spacings in non-quirk mode (i.e. with DTD statement)?.
Answer: This is another issue altogether.
1. According to one interpretation of CSS2, the line-height (default or otherwise) of a parent block level element specifies a 'minimal' line height for any inline content [3].
And since IMG is an inline element, it will have a line-height of at least that of it's parent. This is how Mozilla works in 'standards (i.e. non-quirks) mode'.
If the image is smaller than the line-height, then there will be space above the image. However, this is normally only a problem for very small images, and can be got round by specifying a line-height of zero on the parent element.
2. Inline elements are by default vertically aligned on the baseline of a line box [4], which is again what Mozilla always does in 'standards mode'.
IE, on the other hand, if the block element contains only inline replaced elements (e.g. IMGs), will by default align them with the bottom of the line box.
Explicitly specifying 'vertical-align:bottom;' on the IMG should lose any bottom space - and the aforementioned 'line-height:0;' can be used as well as long as there is no text in the cell:
td {line-height:0;}
td img {vertical-align:bottom;}
References:
[1] http://www.w3.org/TR/REC-CSS2/tables.html#borders
[2] http://www.w3.org/TR/REC-CSS2/tables.html#separated-borders
[3] http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-line-height
[4] http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-vertical-align
Regards, Val Sharp - Edinburgh
ANOTHER RESPONSE First; if have an HTML "strict" declaration in your page - which makes Mozilla (and NS6x) go into what they have called "standards compliant rendering mode".
This in its turn means that the default vertical alignment of e.g. replaced elements inline boxes (images) gets a 'vertical-align' at 'baseline', i.e the baseline of the first row of text in the table cell. Now you don't have any text there but there is still a baseline available in the cell and your image is "standing" on that line.
So effectively what you are seeing is the reserved space for descenders on characters like 'p q y' in your current table cell font.
You need to explicitly set a style rule for your TD elements like...
TD { vertical-align: bottom; }
...to change Mozillas initial value of 'baseline'.
For further info see section "17.5.3 Table height algorithms" in the CSS2 specification...
http://www.w3.org/TR/REC-CSS2/
...mind you that the text of 17.5.3 is "confusing" to say the least, and lots of arguments has been thrown around on whether Mozillas chosen route is correct or not as per CSS2 specs. Other browser vendors selected to do it differently.
I have seen no consensus yet though...
Rex .. <rex@css.nu> .. <http://css.nu/>
AND ANOTHER It is the vertical alignment of the image elements.
From CSS2:10.8 "Line height calculations: the 'line-height' and 'vertical-align'
properties" http://www.w3.org/TR/REC-CSS2/visudet.html#propdef-vertical-align, we
learn that the initial value of the 'vertical-align' property is
'baseline'. From the definition of the value 'baseline', we read, "If
the box doesn't have a baseline, align the bottom of the box with the
parent's baseline."
The baselines of the table cells leave room for descender strokes in
the font and that room is the space that you have observed. To
eliminate the unwanted space, use the following rule set.
img { vertical-align: text-bottom; }
As noted, cell spacing, cell padding, and cell borders are not creating the problem that you want to solve. Nevertheless, if you want to visually eliminate those things, use the following rule sets, which include redundancies.
table {
display: table;
table-layout: fixed;
border-collapse: collapse;
border-spacing: 0em 0em;
border: none 0em;
border-style: hidden;
padding: 0em;
}
colgroup, col, thead, tfoot, tbody, tr {
margin: 0em;
border: none 0em;
border-style: hidden;
padding: 0em;
}
th, td {
display: table-cell;
margin: 0em;
border: none 0em;
border-style: hidden;
padding: 0em;
}
Etan Wexler
FOLLOWING UP TD { vertical-align: bottom; }
However, that breaks in Opera and doesn't work in Mozilla, if line-height exceeds image height. display: block; is safer.
http://www.hut.fi/u/hsivonen/standards.html#img-display-block
Henri Sivonen