Re: Fwd: Proposal for limited :matches pseudoclass

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 UTC