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

On Mon, Sep 28, 2009 at 2:31 AM, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:
> 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 elements.
>
http://dev.w3.org/2006/webapi/selectors-api2/#scoped-selector-string

The proposal for detecting support is then try catch? As in:

  IS_SCOPED_SELECTOR = false;
  try {
    document.querySelector("!a");
    IS_SCOPED_SELECTOR = true;
  } catch(ex) {}

?

I don't see a form of a "createSelector" method there.

Garrett

Received on Monday, 28 September 2009 15:43:38 UTC