W3C home > Mailing lists > Public > www-style@w3.org > June 2011

Re: CSS Hierarchies / Selector Nesting Proposal

From: Andrew Fedoniouk <andrew.fedoniouk@live.com>
Date: Thu, 2 Jun 2011 23:54:23 -0700
Message-ID: <BLU165-ds9B0CB54E14E182E4940E0F87F0@phx.gbl>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, "Brad Kemper" <brad.kemper@gmail.com>
Cc: "Boris Zbarsky" <bzbarsky@mit.edu>, <www-style@w3.org>
Consider following rules that I have:

input[type=button],
button
  {
     style-set: std-button;
  }

@style-set  std-button
{
    :root { background: url(theme:button-normal); }
    input:root { content: attr(value); }
    :root:disabled  { ... }
    ...
}

Note 'input:root' inside the style set, it defines
style of the element itself when the style set
is applied to the <input> element only.

I am not sure how such situation is supposed to
be defined with the '&' construct. Tag names in CSS selectors can
appear only at the start of selector.
The notation should support something like '&input', right?

Another thing about style sets as named style collections. Here is an 
example of
defining custom scrollbars:

@style-set my-vertical-scrollbar
{
   :root {...}
   .next {...}  /* all scrollbar parts ... */
   .next-page {...}
   .slider {...}
   ...
}

And to apply such style set to scrollbars of some of elements is a matter
of defining:

div.scrollable
{
    vertical-scrollbar: my-vertical-scrollbar; /*name of style set*/
}

That is quite useful and popular construct.

If to extend SASS idea further to support such things we need to allow style 
blocks to
be legitimate property values on grammar level.

And yet I am not sure how SASS will be reflected in CSSOM. In general if you 
have
something like this:

#foo {
   &>#bar {  ... }
   &>#ozo { ... }
}

you will want to delete all contained rules when you delete "master" rule 
#foo.
The same about other manipulations like cloning, etc.
So what exactly that compound SASS style block is?
Is it just a preprocessor (pure parse time)  feature or is it rather a style 
set - set of rules
that are applied on all-or-none basis?


-- 
Andrew Fedoniouk

http://terrainformatica.com


-----Original Message----- 
From: Tab Atkins Jr.
Sent: Thursday, June 02, 2011 9:35 PM
To: Brad Kemper
Cc: Boris Zbarsky ; www-style@w3.org
Subject: Re: CSS Hierarchies / Selector Nesting Proposal

On Thu, Jun 2, 2011 at 12:16 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
> On Jun 2, 2011, at 9:09 AM, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:
>
>> On 6/2/11 11:48 AM, Brad Kemper wrote:
>>> OK, I see the issue now. By inserting the ampersand token, you are being 
>>> more explicit with regard to space handing.
>>
>> Yeah, the use of ' ' as a combinator is sort of killing us here.  :(
>>
>>> If the use case for each of those two examples is equally strong
>>
>> I think that the use cases for the "#foo.bar" and "#foo .bar" selectors 
>> are equally strong, yeah.  They're both pretty commonly used.  For 
>> ":hover" instead of ".bar" the use case for the descendant combinator is 
>> less strong, but I don't think we should have different parsing rules for 
>> ":hover" and ".bar" here.
>
> I meant in terms of embedding one ruleset inside another, are the 
> organizational benefits the same for pseudo-class selectors as for 
> defendant selectors? Or would the tradeoff of not embedding the 
> pseudo-class rule inside another rule be worth it in order to not have to 
> write as many ampersands, as you could still write the pseudo-class rules 
> normally and be reasonably organized with a net gain overall. I'm more or 
> less playing devil's advocate here, as I suspect the answer is "no".

It's definitely still very valuable.  For example, if you have a
relatively long selector to select a button, you can use nesting to
style the :hover and :active states without repeating yourself.

There are similar use-cases for having a pseudo with a descendant
selector - for example, selecting an element via a long selector, then
targeting an :nth-child() of the element.

~TJ
Received on Friday, 3 June 2011 06:54:53 GMT

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