Or at least, current implementations of it. I spent at least 4 hours today trying to get something to look similar in Internet Explorer and Firefox. In most regards, IE works right much more of the time and renders more elements as would be expected. IE has a few strange quirks, but better supports actual styles that people might want to use.

For example: I have pages with this structure:

<div class="param">  <span class="name">Paramater Name</span>  <span class="value">Parameter Value</span></div>

Now, I have a bunch of these in a row. I want all the parameter VALUEs to line up vertically. I want a gray horizontal line below each pair of values.

• How I want it to look, which is easy in Internet Explorer:
  
• This seemingly simple layout is very hard to also achieve in Firefox.

Conclusion: In IE, it’s a piece of cake. We specify the “width” parameter in the CSS style for the “name” class to be a fixed 120px or 100pt. But this has no effect in FireFox/Navigator, because in FF “width” is not supported for INLINE elements such as SPAN. FF just ignores the width.

I tried this potential solution:

1. Making the “name” style definition contain “float: left”. Adding an extra “<div class=”clear”></div>” after the “value” DIV tag in my page structure. But… I don’t want to change the page HTML structure; that’s the whole point of CSS. Also, I want a bullet to the left of the NAME class and this was accomplished by defining NAME to be a list-item. By setting the NAME to float-left, the bullet is no longer positioned properly in IE (it oddly moves to the right of the text).

So I’m goin’ back to tables for now, unless someone stumbles on this article and writes with a solution. Regardless of what they say about content/presentation separation, CSS makes layouts which were easy with tables extremely difficult if impossible to achieve, especially when cross-browser compatibility is necessary. CSS doesn’t separate content and presentation well when extra tags (such as the “clear: both” empty container) and great care need to be taken when preparing the content so that specific presentations will work.

A lot of the compatibility issues, in turn, can be blamed on the fact that the CSS spec leaves many trivial-appearing details unspecified. Then it’s not surprising when different implementations do things differently, and we poor designers/programmers deal with the annoyances that result.

So I don’t hate CSS, just the fact that it’s promoted as an end-all solution to Web design when that turns out to be far from the truth, at least based on the amount of time I’ve spent grappling with stupid compatibility bugs.

XML and XSLT, perhaps? Time to learn how to use these.