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

Re: [css-selectors] :contains()

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 25 Apr 2012 18:24:19 -0400
Message-ID: <4F987993.8080909@mit.edu>
To: www-style@w3.org
On 4/25/12 6:09 PM, Sebastian Zartner wrote:
> But isn't that something, which
> should in most cases be done within milliseconds?

The real question is how often you have to do it.  Doing it once is ms 
(or likely even faster).  Doing it thousands or tends of thousands of 
times a second, as the page mutates its DOM, is where the problem comes up.

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

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

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 ~ 

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.

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.

Of course in a non-dynamic context a lot of these concerns are less 

Received on Wednesday, 25 April 2012 22:24:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:58 UTC