W3C home > Mailing lists > Public > www-style@w3.org > April 2012

Re: [css-selectors] Subject marker

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 26 Apr 2012 03:11:24 -0400
Message-ID: <4F98F51C.7020809@mit.edu>
To: www-style@w3.org
On 4/26/12 2:31 AM, Sebastian Zartner wrote:
> As I understood the subject marker this is incorrect. You would only have to style the<ol>  in dependency of having exactly one<li>  in it. The<li>  (or any other descendents) wouldn't be affected.

Sure they would, because some styles inherit.  So changing 'color' on 
the <ol>, say, might change it on all descendants.  Or might not, 
depending on their styles.

> But what's the difference to 'OL LI:only-child' here? There you also have to walk up the ancestor chain looking for<ol>s. The only difference is that you style the<ol>  and not the<li>.

Yes, that's the difference.  When something changes about the <li>, 
right now you know you don't need to restyle any ancestors of the <li> 
(modulo :empty), so you can constrain your search for the set of things 
that need to be restyled.  With subject markers, the set of things that 
might need to be restyled for a change is much bigger (and in fact is 
the whole document, generally).

>> And with some of the other proposals people want to combine this with,
>> you could end up restyling arbitrary other nodes in the DOM that are
>> far away from the 'OL'.
> Do you have examples for these other proposals?

They basically come down to things that allow you to select some 
arbitrary descendant of an arbitrary ancestor of some node that matches 
a given selector.  In other words, any change to any node might affect 
styles anywhere in the document.

> Of course finding out which selectors start and which stop matching is not a trivial task, but it can be optimized in most cases.

Yes, I'm obviously well aware.  The point is that even _after_ 
optimizing it's not that fast.

> In the example above the style stops matching as soon as another child element is inserted or all child elements are removed. Based on this information triggers can be written that execute at these events and restyle the elements they are applied to. If these elements are the ones you matched against or any others of the selector shouldn't be a difference then.

I suggest you think through the set of special-cases like this needed to 
deal with all the selectors in CSS.

Then think about how long it'll take to check for each of the special 
cases on each mutation....

>> Again, the subject marker may well be worth it.  Just please don't
>> pretend it doesn't cost anything performance-wise: it makes every
>> single mutation somewhat slower.
> When you think this is going to be slow in many cases, then it might help if you gave examples.

Examples of what?  Again, the biggest cause of slowdown is restyling a 
large part of the DOM on some mutation.  The second-biggest cause is 
spending too long figuring out that you don't need to restyle things. 
Any selector which makes the former more likely and the latter harder 
means performance problems unless a great deal of effort is spent on 
mitigating them.

> This sounds like we agree on allowing the subject marker and :contains() within querySelector().

I think it would be fine there, yes.  It might be find in dynamic 
contexts too; it's just that no one has figured out how to make it work 
well.  If you have a selectors implementation that deals with the 
problem that you're willing to share, I'm sure people would be very 
interested!

-Boris
Received on Thursday, 26 April 2012 07:11:58 GMT

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