Re: [selectors-api] Summary of Feature Requests for v2

On Thu, Sep 24, 2009 at 11:38 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 9/24/09 2:17 PM, Garrett Smith wrote:
>>
>> On Thu, Sep 24, 2009 at 6:06 AM, Boris Zbarsky<bzbarsky@mit.edu>  wrote:
>>>
>>> Gecko doesn't.  Webkit doesn't.
>>>
>>> I just checked really quickly, and on my machine (a year-plus old laptop)
>>
>> That is probably many times faster, and can probably be much more
>> liberal, than an optimized browser running on a mobile device with 128
>> MB RAM.
>
> Did I imply it's slow?  I just listed approximate hardware so that the times
> can be placed in some sort of context.

No, you did not say it is slow. I'm saying that your laptop is
probably a lot more powerful than a mobile device with a browser, such
as Blackberry9000. Do you agree with that?

>
> that said, note that on a mobile device with 128 MB of RAM the RAM is a lot
> more likely to be a problem than the CPU in some ways.  Running out of
> memory is strictly worse than being a little bit slower.  So a lookup table
> may be more of a loss than a win, depending.

An internal cache for matchesSelector (a lookup table) would be an
implementation detail, wouldn't it?

The idea for QuerySelector.create is the result would be an object
that the program could hang on to. It would not be recreated and
garbage collected each time.

element.matchesSelector would be recreated and collected each time.

The QuerySelector puts selector-related behavior on the selector, not
related to nodes.  For example a match method could match a selector
from a context node:

selector.match( contextNode );

A hand-rolled UserPanel might want to have a delegating listener to
check to see if an LI was selected from a list. So, the delegating
listener would be applied to each Panel instance, checking to see when
an item was selected.

Garrett

Received on Friday, 25 September 2009 05:36:06 UTC