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 09:51:05 -0700
Message-ID: <4BBA14F9.2060901@inkedblade.net>
To: Brad Kemper <brad.kemper@gmail.com>
CC: www-style@w3.org
On 04/01/2010 07:52 AM, Brad Kemper wrote:
>
> On Apr 1, 2010, at 3:52 AM, Axel Dahmen wrote:
>
>> "Brad Kemper"<brad.kemper@gmail.com>  schrieb im Newsbeitrag news:7e1f93761003301034j2ed9ecd2k89228c5a57c2e04a@mail.gmail.com...
>>
>>> A few of us did, anyway (it wasn't part of the minuted meeting
>>> of everyone present). I also posed the idea of list-style-type
>>> being a sort of shorthand for ::marker { content: \ 2022; },
>>> but that causes problems with the cascade.
>>
>> I understand. As far as I can see, ::marker is the only element with generated textual content, allowing two rules to contradict each other.
>
> The don't contradict; the one with the higher specificity overrides.

That's not quite the story here. What happens here is that the initial
value of the 'content' property, 'normal', when specified on a marker,
calculates its value from the 'list-style-type' property on the marker.
If you change the value of 'content' on the marker to something else,
you lose this behavior: 'list-style-type' is then ignored. If you set
it back to 'normal', it will take its value from 'list-style-type' again.

When you combine this behavior with the cascade, it means that if you're
going to mess with the 'content' property on ::marker, you'll need to
reset it to 'normal' whenever you set 'list-style-type' in your style
sheet. Since this can get pretty confusing, it's better IMO to leave
direct 'content' manipulation for cases that are either uncommon or
impractical to cover in 'list-style-type', and define 'list-style-type'
values for straightforward and common things like custom bullet characters.

> This is an integral behavior of CSS, and this is certainly not the only place
> where one one property overrides another.

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.

This is the fundamental problem with introducing e.g. margin-start--
pseudo-elements like ::outside create a similarly tangled-up situation.

~fantasai
Received on Monday, 5 April 2010 19:12:07 GMT

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