Re: QSA, the problem with ":scope", and naming

> This is _very_ hard to reasonably unless the browser can trust those
> functions to not do anything weird.  Which of course it can't.  So your
> options are either much slower selector matching or not having this. Your
> pick.

This too has come up in some discussions on CSS (CSSOM I think) that I
have had.  In the right context - I don't think it would actually be
that hard.  It would require a way to provide a sand-boxed evaluation
(read only elements) and a pattern much like jquery's where it is a
filter which can only return true or false.  True enough that it would
be slower than native for a few reasons - but perhaps still useful.


On Tue, Oct 18, 2011 at 4:40 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 10/18/11 4:20 PM, Yehuda Katz wrote:
>>
>>  * Speeding up certain operations like `#foo` and `body`. There is *no
>>    excuse* for it being possible to implement userland hacks that
>>    improve on the performance of querySelectorAll.
>
> Sure there is.  One such "excuse", for example, is that the userland hacks
> have different behavior from querySelectorAll in many cases.  Now the author
> happens to know that the difference doesn't matter in their case, but the
> _browser_ has no way to know that.
>
> The other "excuse" is that adding special cases (which is what you're asking
> for) slows down all the non-special-case codepaths.  That may be fine for
> _your_ usage of querySelectorAll, where you use it with a particular limited
> set of selectors, but it's not obvious that this is always a win.
>
>> This may be the result of browsers failing to cache the result of parsing
>> selectors
>
> Yep.  Browsers don't cache it.  There's generally no reason to.  I have yet
> to see any real-life testcase bottlenecked on this part of querySelectorAll
> performance.
>
>>    or something else, but the fact remains that qSA can be noticably
>>    slower than the old DOM methods, even when Sizzle needs to parse the
>>    selector to look for fast-paths.
>
> I'd love to see testcases showing this.
>
>> jQuery also handles certain custom pseudoselectors, and it might be nice
>> if it was possible to register JavaScript functions that qSA would use
>> if it found an unknown pseudo
>
> This is _very_ hard to reasonably unless the browser can trust those
> functions to not do anything weird.  Which of course it can't.  So your
> options are either much slower selector matching or not having this. Your
> pick.
>
> -Boris
>
>

Received on Tuesday, 18 October 2011 21:02:06 UTC