W3C home > Mailing lists > Public > www-style@w3.org > July 2008

Re: Proposal for limited :matches pseudoclass

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 31 Jul 2008 02:47:00 -0700
Message-ID: <48918A14.6010604@mit.edu>
To: Francois Remy <fremycompany_pub@yahoo.fr>
CC: www-style list <www-style@w3.org>

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
Received on Thursday, 31 July 2008 09:47:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:10 GMT