[css-selectors] Subject marker

As there are now two topics we're talking about I split up the conversation about the subject marker from the one about :contains() [1].

> > Also I assume defining the subject of a selector doesn't cost any
> > additional performance because it's just marking, which element(s)
> > inside the selector should be styled.
> > So having 'OL! > LI:only-child' (as from the spec) would first find 
> > all
> > <li>s, which are the only child of a <ol> and mark the <ol> for 
> > styling at the same time.
> 
> Again, it matters for dynamic changes.  For example, if I have an <li> 
> with no kids and I insert a child, then the selector 'OL! > 
> LI:only-child' means I have to recompute style on the parent OL and all 
> its descendants.
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.

> The selector 'OL! LI:only-child' would require walking up the ancestor 
> chain looking for OLs and recomputing the style starting that topmost 
> thing found.
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>.

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

> Basically, a UA has three options:
> 
> 1)  Give up on correctly handling dynamic changes; just accept that 
> sometimes styles won't update (already taken by some UAs for the + and ~ 
> combinators).
> 
> 2)  On every change, just restyle the whole document.
> 
> 3)  On every change, try to figure out what part of the document 
> actually needs restyling.
> 
> In practice, #1 is not that great, and #2 is very expensive, so UAs 
> want to do #3, and the cost of _that_ goes up with the subject marker.
>
> For general CSS, though, you have to match *dynamically* - every time
> the document is changed, you must quickly find which selectors stop
> matching, and which new selectors start matching.  This is *not* a
> trivial task, and it has to be done *quickly*, so that things like
> :hover feel responsive.  Some features make this much harder, like
> :contains() and especially the subject selector.  It might be possible
> to do dynamic matching quickly, but it's a non-trivial task.  And
> what's worse, the mere *presence* of one of these slow rules can
> potentially slow down matching for the entire page, even if it never
> actually matches anything.
Of course finding out which selectors start and which stop matching is not a trivial task, but it can be optimized in most cases.
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.

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

> Of course in a non-dynamic context a lot of these concerns are less 
> relevant.
This sounds like we agree on allowing the subject marker and :contains() within querySelector(). So we will end up with splitting the selectors into a static and a dynamic part as Tab Atkins mentioned it [2].

Sebastian

[1] http://lists.w3.org/Archives/Public/www-style/2012Apr/0725.html
[2] http://lists.w3.org/Archives/Public/www-style/2012Apr/0380.html
-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

Received on Thursday, 26 April 2012 06:32:31 UTC