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

[selectors4] specificity of :matches as ancestor

From: Peter Moulder <peter.moulder@monash.edu>
Date: Fri, 19 Apr 2013 11:27:43 +1000
To: www-style@w3.org
Message-id: <20130419012743.GA30728@bowman.infotech.monash.edu.au>
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.

One can speed up special common cases such as where there is no more
specific sub-selector argument, but that just means that one needs to
implement both the search and the optimization.

I haven't implemented it yet, but it looks like it's going to involve
backtracking machinery.  The extra complexity makes me wonder whether it's
worthwhile, and wonder whether all implementations will actually do this
search: it seems like it won't often actually make a difference.  This
added complexity and interoperability concerns are starting to make the
previous fixed max-of-all-arguments specificity behaviour look more
appealing.

The decision could still go either way, depending on how strong the
call is for the same-as-expanded specificity behaviour is compared to
interoperability concerns and implementation cost.  These downsides could
be somewhat quantified just by implementing the thing and briefly reporting
on it (lines of code, complexity for testing and understanding the code).
Maybe it'll turn out to be cheap, but I wanted to make sure that at least
everyone's aware that there is a new search involved where previously the
:matches test was self-contained like any other selector.

pjrm.
Received on Friday, 19 April 2013 01:28:08 UTC

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