Fwd: Proposal for limited :matches pseudoclass

blarg forward to list


On Thu, Jul 31, 2008 at 4:47 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

>
> Francois Remy wrote:
>
>> http://www.w3.org/TR/2001/CR-css3-selectors-20011113/#content-selectors
>>
>
> That's a pretty out-of-date draft.  Recent drafts don't have :contains
> because no one implemented it.  Largely because of the performance issues.
>
> See http://www.w3.org/TR/css3-selectors for the current draft.
>
>  It's quite stupid to think :matches cost more than :contains
>>
>
> Indeed not.
>
>  since :matches en :contains are both to be reevaluated when an element is
>> added
>>
>
> Or removed.
>
>  We don't need to implements a partial :matches because a whole :matches is
>> easily possible.
>>
>
> That's good to hear.  I look forward to seeing a detailed algorithm for
> implementing it plus the notification system needed for efficient style
> reresolution when the DOM is mutated.
>
>  If a developer want to make a buggy selector, it don't need :matches to do
>> it.
>>      :root > * * * *:hover * * * * *:contains(e) * * { color: red; }
>>
>
> I see nothing buggy in this selector, nor anything that would take
> significant processor time to deal with (apart from the :contains, which as
> I already mentioned is no longer in CSS3 Selectors).
>
>         a b::before {content:'[[X-CONTENT-B]]'; display: none; }
>>        a:contains([[X-CONTENT-B]]) > c { ... }
>>
>
> Of course that wouldn't work, even if :contains were implemented (since the
> generated content is not in the DOM).  But the point that :contains is more
> expensive stands.
>
> -Boris


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".  I suspect (though am open to
corrections) that "foo:matches(> bar)" is the same complexity as "foo > bar"
as well.  Is this correct?

If so, would it be correct that "foo:matches(~ bar)" would be the same
complexity as "foo ~ bar"?  If so, I'd like to amend the proposal to allow
that as well.

>From all that you've said, it appears that it's only testing for general
descendants that really starts incurring performance costs.  Is this true?

What about arbitrary selectors that don't include the descendant
combinator?  Would "foo:matches(> bar + baz)" get into the "too
computationally expensive" camp?  What if we allowed multiple selectors, but
they were restricted to using the same combinator, such as "foo:matches(+
bar + baz + qux)"?  Is this more difficult for the matcher than "foo + bar +
baz + qux" is?

(Full disclosure: I'm a programmer by trade, as many on the list are, but I
obviously don't have experience with CSS engines.
  So I *can* understand and generalize your answers, but I prefer not to
make assumptions before getting knowledge from someone who knows better.)

~TJ