Re: Proposal for limited :matches pseudoclass

On Thu, Jul 31, 2008 at 4:43 PM, Simetrical <simetrical@gmail.com> wrote:

> 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.


I'm not sure I get you here.  Given "foo + bar", a DOM mutation could
certainly recompute the style of descendants.  It would simply be the
descendants of bar that possibly get recomputed styles, whereas in
foo:matches(+ bar) it's foo's descendants that may need recomputation.  Is
there something I'm overlooking here that allows you to avoid recomputing
styles upon a DOM mutation if you use the "foo + bar" rule?

"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.


Same objection as above.  What about "foo:matches(~ bar)" requires a bunch
of recomputation that "foo ~ bar" does not?  It seems that "foo ~ bar" would
require recomputing style for all *following* siblings of foo.  I understand
that "foo ~ bar" all by itself is a fairly inefficient selector that
generates a lot of work when used, but it was still implemented.  In my head
"foo:matches(~ bar)" generates the same amount of work, and thus wouldn't
fall under the "too slow to implement" argument.  The + and ~ combinators
just seem to be perfectly symmetrical (haha!) regarding their use in normal
expressions or :matches() expressions.

I understand why the child and descendant combinators are *not* symmetrical,
and why the :matches() versions are more work (in the descendant
combinator's case, a *lot* more work).  As you say, "foo > bar" *can't*
trigger style recomputation in foo or foo's other children, while
"foo:matches(> bar)" can.  (And "foo:matches(bar)" can trigger style
recomputation cascading from arbitrarily high in the document!)  It is my
hope, though, that "foo:matches(> bar)" isn't *overly* complex, and would be
possible to implement.  Boris' remarks in the prior thread on this topic
indicated that he believed, at least offhand, that a :has-child()
pseudoclass wouldn't be impossible (which is exactly what :matches(>) is).
Of course, he is free to revise his opinion if I drew the wrong conclusion.


> 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).


Well, use-cases have already been advanced.  At least for the :matches(+)
and :matches(~), the use-cases are *identical* to the plain + and ~
combinators.  If you can find a use for one version, you can find a use for
the other version.  The use-cases for :matches(>) are somewhat more limited,
but there are many important ones.  One that has come up a few times is
styling the container of a checkbox/radio input based on the input's
:checked state.  This is impossible to do with CSS currently, but here it
would be foo:matches(> :checked).  I've also had several times in my design
experience (one just earlier this week!) where I've wanted to style an
element based on its children, but instead had to push the relevant info
into a class on the parent.  This is usually manageable, but it's definitely
inconvenient and I'd prefer it to be in the CSS if at all possible.

~TJ