Re: Proposal for limited :matches pseudoclass

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