W3C home > Mailing lists > Public > www-style@w3.org > April 2013

Re: [selectors4] specificity of :matches as ancestor

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 18 Apr 2013 18:37:04 -0700
Message-ID: <CAAWBYDATrndVRM6cMWL5HeO3V2W_Vjdivp08qFbmmsEz7Gv8Gw@mail.gmail.com>
To: Peter Moulder <peter.moulder@monash.edu>, www-style list <www-style@w3.org>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:10 UTC