- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 05 Apr 2010 14:25:35 -0700
- To: Brad Kemper <brad.kemper@gmail.com>
- CC: "www-style@w3.org" <www-style@w3.org>
On 04/05/2010 01:54 PM, Brad Kemper wrote: > On Apr 5, 2010, at 9:51 AM, fantasai <fantasai.lists@inkedblade.net> wrote: > >> Cases where one property always overrides the other are messy wrt the >> cascade, and should be avoided. It's easy to think, "oh, well, we'll >> just design a new property that, when set, always overrides the old >> property" because in many languages, that works no problem. But in CSS >> it royally screws with the cascade, since once you use the new property, >> higher-specificity rules with the old property no longer have an effect. > > I wasn't aware of this wrt list-style-type. I had assumed that the in > the following, the 'content' would be reset to a disc in the more > specific case: > > ol li::marker { content:'brad'; } > ol > li#not-brad{ list-style-type:disc; } > > Any reason why it couldn't work like that? Let 'list-style-type' mean > exactly the same thing as 'content:<Unicode of disc>'? And vice versa? At what point would that equivalency happen? Note that 'list-style-type' is inherited, 'content' does not inherit, and inheritance happens after the cascade, not before. The relevant part of the spec is CSS2.1 Chapter 6, which is deceptively simple. It's probably one of the most fuzzily-understood parts of the spec by people (including WG members) proposing new features. But it's also what determines whether a feature can or cannot work reasonably well in the CSS model. ~fantasai
Received on Monday, 5 April 2010 21:26:14 UTC