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.

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