Re: [css3-selectors] Grouping

Tab Atkins Jr. wrote:
> On Fri, Jan 8, 2010 at 7:55 AM, Nikita Popov <privat@ni-po.com> wrote:
>> It would be much more convenient to group parts, that aren't changing:
>> .add
>> (#authors input, #authors select, #authors textarea,
>> #publications input, #publications select, #publications textarea)
>> {
>> ...
>> }
>>
>> Or even
>> .add (#authors, #publications) (input, select, textarea)
>> {
>> ...
>> }
>>
>> The code gets shorter and more readable.

Usual advice is to assign proper classes to elements.
(But I shall admit that is not even possible in some CSS use cases)

> 
> 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.

Even opposite, such forms as:

   .add (#authors, #publications) (input, select, textarea)

may easily lead to even more rules that needs to be handled.

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,

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Friday, 8 January 2010 17:13:17 UTC