Re: [css-selectors] :contains()

>> So the same person refusing to implement :contains() with the argument
> of performance issues also keeps the subject selector from being
> implemented for the same reason.
> 
> You make it sound like a conspiracy! ^_^  Browser implementors have
> specialties, and implementing selectors efficiently is difficult.
> There's only a few people in each browser who can do it well.
Intentionally. :-) Of course I do not doubt in the abilities and knowledge of browser implementors.
I just want to hear the opinion of different browser implementors and get to know in which cases these selectors will kill performance. And maybe someone can come up with an idea of how to keep the overhead on these selectors small.
Therefore we'll need some more examples (fast and slow performing ones).

> > Are there already measurements, which verify these concerns? From an
> > outsider view I see IDEs like Eclipse searching text in hundreds of
> > files within a second. So can somebody explain me what's the problem 
> > to search for text in some text passages?
> > Of course a '*:contains("long text to check so that this selector
> > matches")'
> > selector will generally perform worse than a '#element:contains("a")'
> > selector. But isn't that something, which should in most cases be done
> > within milliseconds?
> 
> (Comparing this to programs that are designed to search across large
> bodies of text isn't very useful, though - if you *know* that the
> common case is people opening up the same sets of files for long
> periods of time, you can optimize your search by building an index and
> make most text searches *really* fast.  Browsers don't have this
> luxury, because the common case is people loading up lots of
> different, dynamic files that change constantly.)
Sure, these two kinds of searches are not directly comparable.
If :contains() is restricted to direct text node children, you will also be able to optimize the search on these.
I assume text transformations like (e.g. * { text-transform: uppercase; } ) are also expensive.
Of course matching the selector is fast in this case, though checking every single character and change it if appropriate is also taking its time. Though this is already implemented into browsers for a long time.

> For general CSS, though, you have to match *dynamically* - every time
> the document is changed, you must quickly find which selectors stop
> matching, and which new selectors start matching.  This is *not* a
> trivial task, and it has to be done *quickly*, so that things like
> :hover feel responsive.  Some features make this much harder, like
> :contains() and especially the subject selector.  It might be possible
> to do dynamic matching quickly, but it's a non-trivial task.
Sure, but if no one tries, we won't get any further. Also the use cases for :hover and :contains() are quite different. While reacting to mouse moves must be instant reacting to text changes does not forcibly.

> And what's worse, the mere *presence* of one of these slow rules can
> potentially slow down matching for the entire page, even if it never
> actually matches anything.
Yes, but that counts for all rules. Though of course by having slow rules you'll realize the decrease in page speed faster.

Sebastian
-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

Received on Thursday, 26 April 2012 07:34:04 UTC