[
Lists Home |
Date Index |
Thread Index
]
At 09:15 PM 7/9/2003 -0400, you wrote:
>But once you start getting into doing tricky things with CSS, you learn
>that the rules about what cascades where and how far are really hard to
>grasp and remember. That's even without fussing about specific
>implementations.
The nature of those problems is worth considering, actually - it reinforces
the differences between CSS and XSLT. Both CSS and XSLT permit rules to
have different levels of priority, frequently based on how specific the
selector/XPath is. CSS permits direct overrides with a set of rules based
on where the different rules came from, with a general pattern of
closer-to-the-instance-wins. XSLT regards direct rule conflicts as errors,
though not all processors report them.
The places where the cascade gets tricky tend to be places which reflect
the politics of web design - who has control over final presentation? In
my experience, graphic designers want control over all presentation and
hate being overruled, so the W3C gave them !important rules. Users
frequently hate dealing with what graphic designers give them, so they want
to override the graphic designer's rules, and battles of !important rules
ensue. In CSS1 the designer ("author") would win in conflicts of
!important, while in CSS2 (wisely, in my view) the user would win.
Selector specificity can seem a bit strange, but I like it better than
XSLT's approach - it corresponds more thoroughly to my notion of "how
specific is that".
CSS has also suffered, of course, from a lot of variation in implementation
of these rules, and incomplete support.
http://www.w3.org/TR/REC-CSS2/cascade.html
|
