- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 31 Jul 2008 02:47:00 -0700
- 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 UTC