W3C home > Mailing lists > Public > www-style@w3.org > April 2010

Re: CSS3: Suggestion for another list-style-type

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 05 Apr 2010 14:25:35 -0700
Message-ID: <4BBA554F.9040203@inkedblade.net>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:26 GMT