Re: Supporting Scoped Selectors in Selectors API 2

On Mon, Sep 28, 2009 at 9:05 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 9/28/09 8:46 PM, Tab Atkins Jr. wrote:
>>
>> On Mon, Sep 28, 2009 at 6:49 PM, Lachlan Hunt<lachlan.hunt@lachy.id.au>
>>  wrote:
>>>
>>> It might appear to work for the simple case above, but consider the
>>> following cases:
>>>
>>> elm.querySelectorAll(":reference+p, div div");
>>>
>>> Or the reverse of that:
>>>
>>> elm.querySelectorAll("div div, :reference+p");
>>
>> I'm not sure what the problem here is.  Surely you have to parse the
>> entire string before starting *anyway*.
>
> So.. while this is the way it's done in Gecko and Webkit right now, I see no
> reason that it has to be done that way in the future.  I can easily envision
> a future (once we have cores to spare) in which the parsing and the matching
> of the two selectors here happen on different threads (so 3 threads total: 1
> for parsing, 2 for matching).  In that situation, you might in fact want to
> kick off the selector matching for "div div" before you have parsed the
> ":reference+p".
>
> This is pretty hypothetical at this point, though.  At least for Gecko (and
> I assume Webkit).

That would be... kind of weird.  I guess if you've got effectively
infinite cores, sure, but I'd find it difficult to imagine a time when
parsing a selector string was hefty enough to warrant generating
matcher processes during the parse process, then spending the
additional effort to merge and uniquify the result sets.

As a though experiment, sure, that's interesting.  But I don't think
it'll ever be realistic.  (And if it is, we can hack around the
problem then - some of the solutions *will* handle that well.  But I
don't think it's realistic enough to be affect which solution will be
chosen right now.)

>> What's wrong with saying
>> that, if :reference is found anywhere in the selector, it's a scoped
>> selector string?
>
> It leads to weird fail if part of the selector string is edited?

This is a reasonable critique.

~TJ

Received on Tuesday, 29 September 2009 02:18:41 UTC