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