Re: [Events] A case where on* attributes are required

On Fri, Dec 23, 2011 at 7:17 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 12/23/11 2:09 PM, Ojan Vafai wrote:
>
>> We could limit the performance impact by restricting to simple
>> selectors. But that wouldn't completely address the performance issues
>> and it would limit a lot of useful things you can do with this API.
>>
>
> If we restrict to just element IDs, and in particular to attaching to the
> first element with the given id, I think the performance impact becomes
> pretty close to nil (at least in Gecko).  I'm not sure how much of a
> problem that ends up being in practice, though.


That's an interesting idea. It greatly limits what you can do with the API,
but it does address this immediate use-case. Limiting to IDs would cause
the API to have negligible performance impact in WebKit as well. I guess we
could start with an API that limits to ID selectors and leave open room for
adding other selectors in the future.

I'm curious what other browser developers think. Could this be done
>> without significant performance impact?
>>
>
> That depends on how much the API is used, right?
>
> If it's just a few selector-matching operations per mousemove or whatnot,
> that's not that bad performance-wise.... until people start writing crazy
> selectors.


Right. It makes me a bit sad because I find this API incredibly nice to use
in-practice.

Maybe restricting to simple selectors is the right
functionality/performance tradeoff. Simple selectors are obviously more
expensive than just IDs, but they get back most of the richness of the API
without the unbounded performance implications of generic selectors.

Ojan