W3C home > Mailing lists > Public > www-style@w3.org > September 2009

Re: Supporting Scoped Selectors in Selectors API 2

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 28 Sep 2009 22:05:31 -0400
Message-ID: <4AC16B6B.6000605@mit.edu>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: www-style <www-style@w3.org>
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).

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

Received on Tuesday, 29 September 2009 02:06:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:29 UTC