Note: this page doesn't use my normal global style sheet, in order to help illustrate some examples.
Recently I spent a lot of time dealing with cascading style sheet (CSS) issues both at work and in other projects. While doing so I ran into a bunch of cross-browser issues and couldn't find all the solutions in one place on the net, so I thought I'd write them up for reference.
Unfortunately, the sad reality is that Netscape 4.X is still pretty prevalent. In my particular situation, people using SGIs running IRIX or Linux were a large part of the target audience, so the copout of targetting Internet Explorer only was not possible. And I don't believe at this point that enough people have adopted Mozilla - my personal experiences with it is that it's flakier than the latest versions of Netscape 4.X, even with the Mozilla 0.91 releases.
Netscape doesn't deal with line-height well
Netscape doesn't support a:hover
Netscape deals with inherit properties wrong
The table property doesn't inherit from body
font and font-size don't mix
document.createStyleSheet() breaks in IE if you have a <base> tag
Setting the line-height property can cause inline images to be laid out badly. It looks like Netscape ignores the line-height when it comes to inline images (by "inline" I mean img tags which show up inside p tags). This can cause inline images to overlap text. Avoiding the use of img inside p scope is probably one way of dealing with this, but that's perfectly legal HTML and Frontpage seems to generate a lot of this sort of thing.
The following is an example of a paragraph of text with 200% line-height with a img tag embedded in it. When I look at this in Netscape, the picture of the stones is on top of the second block of text.
Here is the first block of text, before the image. Num alio
genere Furiarum declamatores inquietantur, qui clamant: 'Haec
vulnera pro libertate publica excepi; hunc oculum pro vobis
impendi: date mihi ducem, qui me ducat ad liberos meos, nam
succisi poplites membra non sustinent'?
Here is the second block of text after the image. Et ideo ego
adulescentulos existimo in scholis stultissimos fieri, quia
nihil ex his, quae in usu habemus, aut audiunt aut vident, sed
piratas cum catenis in litore stantes, sed tyrannos edicta
scribentes quibus imperent filiis ut patrum suorum capita
praecidant, sed responsa in pestilentiam data, ut virgines
tres aut plures immolentur, sed mellitos verborum globulos, et
omnia dicta factaque quasi papavere et sesamo sparsa.
Okay, so the a:hover property is eye candy. However, my test audience felt that if underlining was taken out and hover behaviour was not supported, it became difficult to determine what was a link and what wasn't.
Using inherit as a value for a property gives some funky results.
This text's background-color property is set to inherit, which should be white. But it's green in Netscape.
This text's color property is set to inherit, which should be black. But it's green in Netscape.
This text's font-family property is set to inherit, which in Netscape 4.x should be Helvetica. If you're using Netscape now, god knows what you're seeing. (I see Courier.)
Workaround: avoid inherit as a property value.
I set some font properties in a body tag and expected them to propogate everywhere. Instead, I was surprised to see that text in my tables didn't pick up the right font. table doesn't seem to inherit any text properties from body in Netscape and IE, except that font-family alone *is* inherited in IE. (Apparently, this will be fixed in IE 6.0.)
In addition, in Netscape th and tr doesn't inherit from table, and td doesn't inherit from tr. In the following, the table defines the text color to be red, so the table header should be red. The table row overrides the text color to be blue and the td should just inherit that color, so the table row should be blue. In Netscape, everything is black.
| This is a table header |
|---|
| This is a table element |
Workaround: set font properties on table, body, th, tr, and td, all at once.
The font-size property and the <font size=...> tag don't play well together. Suppose that you set font-size to an absolute value, like 24pt, for some text:
This is a chunk of 24 point text. Pretty boring.
Now suppose that in the middle of this text, you've used a <font size="-1" to make some text one size smaller:
This is a chunk of 24 point text, except that this text is much smaller than the rest.
That probably looks a LOT more than one size smaller. The problem is that <font size is computed by the browser, and ignores the style sheet entirely. For example a size of "normal" or "3" is something like 12 or 14 pt in Internet Explorer, depending on your browser text size settings. It doesn't scale up or down if you change the font-size property.
The solution to this is either to avoid the use of the <font size=> tag entirely when using font-size in the style sheet, or to set the font-size property to be "normal". Unfortunately, Frontpage appears to write these out a lot even when using style sheets, making the former difficult; and the latter defeats the point of choosing a font size which "looks good" - normal can be pretty ugly and big on some browsers and platforms.