Re: [css3-selectors] Grouping

On Fri, Jan 8, 2010 at 11:13 AM, Andrew Fedoniouk
<news@terrainformatica.com> wrote:
> Tab Atkins Jr. wrote:
>> On Fri, Jan 8, 2010 at 7:55 AM, Nikita Popov <privat@ni-po.com> wrote:
>>> 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)

It's kind of ridiculous to throw classes around just because you, say,
want all your form elements to have a particular styling, or want to
set a border on all your text inputs and textareas.  All the
information you need is already there in the document, it's just
annoying to write at the moment because you're forced to double the
rule.

>> 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's not meant to reduce that.  I agree that, computation-wise, it's
identical to writing them all out long-form, like we do currently.  My
point was that it's not *worse* than writing them out long-form, and
it's much easier for us humans to actually write, so it's a net win
with no performance cost.  Pure syntax sugar.

> Even opposite, such forms as:
>
>  .add (#authors, #publications) (input, select, textarea)
>
> may easily lead to even more rules that needs to be handled.

I'm not sure what you mean here.

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

I really don't think that saying "use of element that matches one of
these sub-selectors" is a complex notion.  Nor is it complex
processing - it just requires a trivial expansion into whatever form
is used to store rules internally for matching.

~TJ

Received on Friday, 8 January 2010 17:19:49 UTC