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

RE: proposal for a new css combinator

From: Niels Matthijs <niels.matthijs@internetarchitects.be>
Date: Wed, 13 Jan 2010 16:18:07 -0000
Message-ID: <EAD6F36F8B8A124FB32D722A828211FD0BDD7EA5@win-s-manc3.shared.ifeltd.com>
To: "Brad Kemper" <brad.kemper@gmail.com>
Cc: "www-style list" <www-style@w3.org>
Short example:


..article header {padding:0.5em;}


..focus header {padding:1em;}

..focus header .header {padding:0;}


When you nest the article component within the .focus component you're
resetting the heading of the article to 0, while it should be 0.5.
Things get even trickier when component A can be nested in component B
and component B can also be nested in component A.


I think the added value of styling a component "as is", "separate from
its context unless the context itself dictates specific rules" is quite



Niels Matthijs



From: Brad Kemper [mailto:brad.kemper@gmail.com] 
Sent: 13 January 2010 17:05
To: Niels Matthijs
Cc: www-style list
Subject: Re: proposal for a new css combinator



On Jan 13, 2010, at 7:22 AM, Niels Matthijs wrote:

>> It's not especially elegant, but gets the job done, I think.


Indeed, but as you stated already, it's not very elegant.


Yes, and I am not saying I am apposed to the idea. I am just trying to
get a feel for how big the improvement would actually be, and how big
the use case is.


1/ when you change something to the focus header you have to reset it
for whatever components are nested


Right, assuming it is a property that you actually want to be different,
and it is not already set to something different. But for inheritable
properties, you may have to do that anyway. For instance, if the inner
header is supposed to have a different font-family, then you are already
creating a separate rule for it, right? Then if you later want to change
the outer focus header's font-family (and not others), then you don't
have to touch the existing rule for the inner header.


	2/ when you nest a new component you have to reset all the
styles again.


I'm not sure I understand what you mean exactly.

 But even worse!


3/ what if the second heading can't be reset. 


Why can't it be reset?

Imagine the focus heading has a padding of 1em. The second heading has a
padding of 0.5em; Depending on where all of this is placed in your css
you have to do a whole lot of rewriting and redefining the same values
(for no good reason really).


I'm not following. If you've got two paddings, then you've already got
two rules. You would only change the ones that you want different. I
must be missing something (in my defense: I've had no coffee yet this

Imo, this is not really acceptable behaviour.  Probably okay and doable
10 years ago, 


Yes, and it seemed in the blog entry that you would prefer IE6, thus my
suggested work-around. 

but if you want to deliver quality work to your clients you should be
able to build more robust and flexible solutions, allowing nestings that
don't pick up any unneeded styles (especially handy when building a
framework where you don't even know what will be nested.


Would scoped selectors help with this?



From: Brad Kemper [mailto:brad.kemper@gmail.com] 

Sent: 13 January 2010 15:36
To: Niels Matthijs
Cc: www-style list
Subject: Re: proposal for a new css combinator



On Jan 13, 2010, at 4:02 AM, Niels Matthijs wrote:

I'm quite sure that someone before me must've thought about this, or
maybe I just didn't look closely enough at the latest specs, but I
believe we are missing an important css combinator.


For the full explanation you can check the following article:


I think in general, you could achieve your aims (including IE6
compatibility) with something like the following, right?


..focusBlock header { /* stying for first level of header in the focus
block */  }

..focusBlock header header { /* reset any styles you don't want in
subsequent header descendants  */  }


It's not especially elegant, but gets the job done, I think.

Received on Wednesday, 13 January 2010 16:27:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:42 UTC