Re: Proposal for limited :matches pseudoclass

On Thu, Jul 31, 2008 at 9:50 AM, Tab Atkins Jr. <jackalmage@gmail.com> 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".

>From Boris' last post, I guess the answer to this is that it's a good
deal more complex, although maybe manageably.  Every time an element
is added, you might need to recompute style for its immediately
preceding sibling.  Of course, if you recompute style for an element
and it turns out that some inheritable property has changed value, you
need to recompute style for all its descendants, which could be a lot.
 On the other hand, "foo + bar" recomputes nothing at all.

"foo:matches(~ bar)" would be worse, because it would require
recomputing style for all preceding siblings.  "foo:matches(> bar)"
would be still worse, because it would require recomputing style for
the parent, which could mean also *all* siblings (preceding or
succeeding).  And "foo:matches( bar)" would be worst of all, because
it could require recomputing style for all *ancestors*, which would
include the root element, and therefore *all* elements.

So a rule like "*:matches( span) { color: red }" would require that
the style of every single element in the document be recomputed *every
time* a span is added to the document.  Including during initial
rendering of the page, and any mutations after that.  Which is
unacceptable.  And the more limited forms you suggest are still worse
than current selectors, but possibly manageable if there's a real need
for them (which AFAICT there isn't).

Am I approximately right here?

Received on Thursday, 31 July 2008 21:49:39 UTC