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

On Mon, Sep 28, 2009 at 2:31 AM, Lachlan Hunt <> wrote:
> Garrett Smith wrote:
>> On Thu, Sep 24, 2009 at 1:28 AM, Lachlan Hunt<>
>>  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.

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

  try {
  } catch(ex) {}


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


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