Re: [css3-selectors] Grouping

>> I've asked for this before, under the :any() pseudoclass.  It works
>> just as you have it - that last rule would be written as ".add
>> :any(#authors,#publications) :any(input,select,textarea)".  It's
>> really a necessity for many cases where you end up with a
>> combinatorial explosion of selectors - this one selector replaces six
>> nearly identical ones.
>>
>> Implementors have agreed that it's basically just syntax sugar, and
>> wouldn't require any special mechanics or cause performance
>> regressions.  It's just not in a draft yet, is all.
>>
> But combinatorial explosion of selectors is still there. Such form
> of notation does not reduce number of CPU ops needed to resolve
> styles of elements.
It is obvious that grouping will not make it faster. That isn't the 
point. Grouping makes it shorter and more readable.
> Even opposite, such forms as:
>
>   .add (#authors, #publications) (input, select, textarea)
>
> may easily lead to even more rules that needs to be handled.
Sure. A feature is only as good as the developer who uses it.
The above rule can be split down into exactly the six rules of the long 
version and therefore does not produce any extra rules.
But obviously you can also extend it to
(#1,#2,#3)(#4,#5,#6)(#7,#8,#9)(#10,#11,#12)
Which would lead to 3^4 = 81 rules. Hopefully nobody does it.

>
> I mean that ideally complexity of notation of selectors should
> reflect complexity of their processing. In this case CSS authors
> will be motivated to keep styles manageable.
>
> As an example:
>
> your
>
>   :any(#authors, #publications)
>
> should be written as:
>
>   :i-swear-i-want-any-of-these(#authors, #publications)
>
> Cheers,
Sorry, I don't understand what you want to say by this.

Tab Atkins said:

>  I've asked for this before, under the :any() pseudoclass.  It works
>  just as you have it - that last rule would be written as ".add
>  :any(#authors,#publications) :any(input,select,textarea)".  It's
>  really a necessity for many cases where you end up with a
>  combinatorial explosion of selectors - this one selector replaces six
>  nearly identical ones.

>  Implementors have agreed that it's basically just syntax sugar, and
>  wouldn't require any special mechanics or cause performance
>  regressions.  It's just not in a draft yet, is all.

Good, that this is already quasi-accepted.
I think that the variant with brackets I proposed is little bit better, 
because it  could  be more widely used, e.g.
input([type=submit], [type=number], ...)
("could" because I don't know, whether something like this, would be 
good...)

Received on Friday, 8 January 2010 17:45:44 UTC