Re: Fwd: Proposal for limited :matches pseudoclass

On Thu, Jul 31, 2008 at 6:17 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

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

Your understanding of the :matches() proposal is correct, and I thank you
for your analysis!

~TJ