Re: [css-selectors] :contains()

On Wed, Apr 25, 2012 at 3:09 PM, Sebastian Zartner
<sebastianzartner@gmx.de> wrote:
>> > I heard that (from [1], for what it's worth) the subject marker is
>> > going to be removed soon for performance reasons, so ... we
>> > probably shouldn't assume that this still exists.
>> >
>>  I assume part of the functionality will arrive in another form then,
>>  because it is one of the most requested features. The generic subject
>>  selector might be overkill, but something similar for just children
>>  and descendants would be more feasible.
>
> 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.

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

As was explained in the bug and in this thread, a *static* match is
easy.  It's certainly more expensive than other operations we
currently allow, but it's still cheap and fast in absolute terms.
This is why it would be fine to have :contains() and other things in
querySelector().

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

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

~TJ

Received on Wednesday, 25 April 2012 22:30:01 UTC