Re: [selectors4] specificity of :matches as ancestor

On Thu, Apr 18, 2013 at 6:27 PM, Peter Moulder <peter.moulder@monash.edu> wrote:
> When the change to :matches specificity was proposed, I'd noticed that
> the change has a slight performance impact on matching because we now need
> to find the maximum-specificity sub-selector instead of just the existence
> of a matching sub-selector; but I hadn't noticed the related performance
> impact on combinator chains, i.e. that a selector like
>
>   :matches(...) :matches(...) :matches(...) p
>
> or
>
>   :matches(...) ~ :matches(...) ~ :matches(...) ~ p
>
> can no longer be content to find the existence of three matching nodes,
> it now needs (in general) to find the most specific combination of
> matching nodes.
>
> This seems to be a more intrusive a change than I'd previously thought was
> involved: it looks like it can in some cases become quite a bit slower than
> with the previous max-of-arguments behaviour (especially with deep trees
> and long chains of combinators), and requires more implementation work
> because it introduces a type of search [or a cartesion product expansion]
> that wasn't previously required in CSS.

Ultimately, it's *exactly* as bad as unfolding the :matches() out of
the selector.  Yes, it's combinatorial in complexity.  But that's the
whole point of :matches() - to hide that complexity in an
easy-to-write form.

~TJ

Received on Friday, 19 April 2013 01:37:52 UTC