Re: Proposal for limited :matches pseudoclass

From: "Boris Zbarsky" <bzbarsky@MIT.EDU>
>
> 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.

OK, I did'nt know that.

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

Yes. I always suppose the deletion when I speak about addition.

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

OK, I will do it.
Please give me some time to do it, I've others activities at the moment.

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

I can assure you that this selector, even without the :contains, need a long 
CPU-time.

In fact, :root > * * * * match (nearly) each elements of the document 4 
times !

<html><body><a><b><c><d><e><f><g><h>Content</h></....>
The :root > * * * * selector can match
    - "html > body a b c", "html > body a b d", "html > body a b e", ...
    - "html > body b c d", "html > body b c e", ....
    - "html > body c d e",  ...
    - ...

So, we get 4 mousein/out handlers attached to all elements matched by :root> 
* * * *:hover.
In addtion, they also receive handlers for DOM mutation events (* added or 
removed into id).

Because we continue to add some * after, elements of the document, the 
complexity is very high.

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

Hum, I checked the old spec and what you say seems to be true.
But as :contains doesn't any more exist, we can leave this point at the 
moment.

Fremy

Received on Thursday, 31 July 2008 10:17:57 UTC