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

Re: [css3-selectors] Grouping

From: Nikita Popov <privat@ni-po.com>
Date: Sat, 09 Jan 2010 09:17:54 +0100
Message-ID: <4B483BB2.7000201@ni-po.com>
To: news@terrainformatica.com
CC: www-style list <www-style@w3.org>
Am 09.01.2010 06:38, schrieb Andrew Fedoniouk:
> Tab Atkins Jr. wrote:
>> On Fri, Jan 8, 2010 at 10:49 PM, Andrew Fedoniouk
>> <news@terrainformatica.com> wrote:
>>> Boris Zbarsky wrote:
>>>> On 1/8/10 12:33 PM, Nikita Popov wrote:
>>>>> Which would lead to 3^4 = 81 rules. Hopefully nobody does it.
>>>> Sure they will.  That's just life.
>>>>
>>>> On the other hand, it's not like stylesheets have small numbers of 
>>>> rules
>>>> as it is.  gmail has several thousand, for example....
>>>>
>>>> The biggest danger here, actually, as with any compression scheme, is
>>>> being a vector for DOS attacks.  And honestly, those are just possible
>>>> already: you could gzip-compress your stylesheet with lots of 
>>>> redundant
>>>> rules and it would end up very small to transmit but huge to parse 
>>>> and such.
>>>>
>>> I have mentioned once already that I've implemented so called style 
>>> sets (in
>>> HTMLayout and Sciter).
>>>
>>> The set is defined as (same syntax as @media section):
>>>
>>> @set somename
>>> {
>>>  ... rules ...
>>> }
>>>
>>> and is applied by the style-set CSS attribute.
>>>
>>> Using sets original task of reducing these 6 rules:
>>>
>>> #authors input, #authors select, #authors textarea,
>>> #publications input, #publications select, #publications textarea
>>> {
>>>  ... rules ...
>>> }
>>>
>>> could be rewritten as:
>>>
>>> @set my-section
>>> {
>>>  input, select, textarea
>>>  {
>>>     ... rules ...
>>>  }
>>> }
>>>
>>> #authors, #publications
>>> {
>>>  style-set: my-section; /* style-set is an inheritable attribute
>>>                            all elements inside #authors will also use
>>>                            rules defined in the my-section */
>>>  ...
>>> }
>>>
First of all and most importantly, I think the grouping or subrule stuff 
is much more convenient.
Your code:
@set formelements
{
  input, select, textarea
  {
     ... rules ...
  }
}
.add #author, .add #publications {
     style-set: formelements;
}
If I now would like to out #author ans #publications in their own set, 
it gets really, really unreadable.
Compare with:
.add (#author, #publications) (input, select, textarea)
Clean, short, effective.
Or same with :any, though not :matches, cause :matches makes it 
complicated again, because breaking it down to simple rules is 
impossible (Any ideas on that?)
>
>> It is similarly simple to say
>>
>> #publications.special :matches(input,select,textarea) {
>>   //new rules
>> }
>>
>> With the same effect.
>>
>
> No. Effect is not the same. For each of 1000 DOM elements you should
> execute at least following check:
>
>   if( element.tag == input ||
>       element.tag == select ||
>       element.tag == textarea )
>
> So in total at least 3000 checks by introducing just one (as author 
> will think) CSS rule. Yes, element.tag == input is a cheap operation 
> but still it should be made.
And now it gets really wrong. If the rendering engines would really do 
that, oh my god!
Sure enough the rendering engines would first jump to the ID 
#publications (which is fast, cause it's a lookup, not a loop), check 
that the class is .special (again a lookup, therefore fast) ans only 
then check for one of the children being a form-interaction-element. So, 
not 3000 checks, but only 302, as many as with your @set-variant!
Received on Saturday, 9 January 2010 08:18:23 GMT

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