- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 28 Sep 2009 22:05:31 -0400
- 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? -Boris
Received on Tuesday, 29 September 2009 02:06:15 UTC