W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

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

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Mon, 28 Sep 2009 11:31:22 +0200
Message-ID: <4AC0826A.10201@lachy.id.au>
To: Garrett Smith <dhtmlkitchen@gmail.com>
Cc: public-webapps <public-webapps@w3.org>
Garrett Smith wrote:
> On Thu, Sep 24, 2009 at 1:28 AM, Lachlan Hunt<lachlan.hunt@lachy.id.au>  wrote:
>> And overload the querySelector() and querySelectorAll() methods to also
>> accept a Selector object as the selector parameter.
>> createSelector would allow the browser to parse and compile the selector and
>> store it, much like createExpression does in DOM 3 XPath.  If a
>> contextElement is provided, then that element is defined as the Scope
>> Element that matches the :scope pseudo-class.  If impliedScope is set to
>> false, the the browser treats it as an ordinary selector.  If it's set to
>> true, then it's treated as an implicitly scoped selector that needs to be
>> pre-parsed into a valid selector and imply the presence of :scope (like
>> ">em,>strong").
> Why not use the selector text for the scope?

I already did that 2 days ago when I dropped createSelector() and found 
a way for it to work with the descendant selector.

The spec now defines that if the selector starts with either a 
combinator (>, + or ~), or an exclamation point, then it's a scoped 
selector, and the processing requirements are adjusted accordingly.  I 
also attempted to define the processing requirements to interpret a 
selector like ">em" as being equivalent to ":reference>em".

I also defined the :reference pseudo class in the spec (formerly known 
as :scope in previous discussions) to match the contextual reference 

Lachlan Hunt - Opera Software
Received on Monday, 28 September 2009 09:32:02 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:19 UTC