W3C home > Mailing lists > Public > www-style@w3.org > July 2008

Re: Fwd: Proposal for limited :matches pseudoclass

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 31 Jul 2008 16:17:42 -0700
Message-ID: <48924816.6010000@mit.edu>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: www-style list <www-style@w3.org>

Tab Atkins Jr. wrote:
> Boris, what are your thoughts on my proposal for a more limited 
> :matches?  From your previous explanations, it seems that a simple test 
> for children and following siblings shouldn't be any worse than existing 
> implemented selectors.  Specifically, "foo:matches(+ bar)" seems like it 
> would be exactly as complex to resolve as "foo + bar".

So that matches a <foo> whose following sibling is a <bar>, right? 
Matching that is pretty easy.  For dynamic updates, what it means is 
that when a node is added/removed we might need to reresolve its 
preceding sibling, or possibly multiple preceding siblings if nesting is 
allowed.  The former certainly doesn't sound too bad.

For "foo:matches(> bar)", if that means "a <foo> which has a <bar> 
child" that means that in genera we need to reresolve the parent of a 
node being inserted or removed (plus of course all its descendants). 
This can be optimized a bit by keeping track of whether such a :matches 
is around and would have to be, because adding children to an 
<html:body> is pretty common during parsing.

>  From all that you've said, it appears that it's only testing for 
> general descendants that really starts incurring performance costs.  Is 
> this true?

What's really a problem is when adding leaf nodes to the document 
requires doing something that is O(N) in the number of nodes already in 
the document.

-Boris
Received on Thursday, 31 July 2008 23:18:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:10 GMT