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

On Thu, Sep 24, 2009 at 1:28 AM, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:
> Sean Hogan wrote:
>>
>> I think a couple of those features are pretty low priority:
>>
>> - I don't see the point of collective queries on NodeLists.
>> Are there any references for the proposal?
>> Otherwise I can't think of any useful queries that can't already be
>> achieved with a single querySelectorAll().
>
> It was discussed a couple of days ago in IRC.  It's based on the
> functionality provided and needed by javascript libraries.
>
> Garrett Smith wrote:
>>
>> Lachlan Hunt wrote:
>>>
>>> div2.matchesSelector(":scope~div", div1);
>>
>> The matching seems backwards. Should be on the matcher, instead of the
>> element? I don't see the role of the element being something that does
>> matching. The matching should be something left to some sort of a
>> Matcher.
>>
>> A function to get an actual Selector object would allow the program to
>> creating a cached matcher.
>>
>> var selector = QuerySelector.create("div.panel");
>> var isPanel = selector.matches(event.target);
>
> That's an interesting concept.  We could perhaps define something like this:
>
> Interface DocumentSelector {
>  Selector createSelector(DOMString selector, [Element scopeElement, [boolean
> impliedScope]]);
> }
> Interface Selector {
>  boolean matches(Node element);
> }
>
> 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?

> A possible extension to consider would be to also allow scopeElement to be
> specified as an array or NodeList of elements, such that :scope will match
> any of the elements in the elements in the array, instead of limiting it to
> just one.
>
> Scripts can then do this:
>
> var selector = document.createSelector(">em,>strong", elm, true);
>
> Or this:
>
> var selector = document.createSelector("h1+:scope>a", [elm1, elm2, elm3],
> false);
>
> And then pass that selector to querySelector*() like
>
> document.querySelectorAll(selector)
>
> And matchesSelector is handled like this:
>
> document.createSelector("input[type=checkbox]").matches(evt.target);
>

Would the boolean "impliedScope" be obvious from selector syntax to
determine scope?

In that way, createSelector would also allow a fair inference for
feature testing the existing selectors engine. methods pretty nicely.

var x = createSelector(":scope div"),
      IS_SCOPE_SELECTOR = x.valid;
x = null;

If so, the program might infer that selector syntax that passed the
validity check could be used for the other selector methods.

var menuItems;
if(IS_SCOPE_SELECTOR) {
  // Get the "LI" child elements with class "menuItem" (direct, not nested).
   menuItems = menuList.querySelector(">.menuItem");
} else {
  // use hand-rolled function.
   menuItems = getChildNodesWithClass(menuList, "menuItem");
}

This allows for:
1) effective reuse of Selector object
2) reuse of browser internal selector API code for Selector object and
other selector-related methods.
3) feature detection of the implementation of supported Selector text.

You also asked for a use case. Finding direct descendants, or "child
elements" is not uncommon situation. The program may want to display
child LI in a list, sequentially timed, and not do anything with the
LI in nested UL/OL.

Speaking of "child elements", there is no convenient way of getting
those and it is sometimes something that a program will want to have
easy access to. The issue over came up over a year and a half ago (I
actually requested it). J Resig also blogged about that. Still no
childElements. Why not? It should be easy to implement and it would be
useful to have a widely supported "childElements" property.

> John Resig wrote:
>>
>> Filtering NodeLists/StaticNodeLists, Queries on NodeLists/StaticNodeLists:
>> Neither of these are useful, as is, to libraries. What is actually useful
>> is
>> the ability to run these against an array (or array-like collection) of
>> DOM
>> nodes.

ECMA says the behavior of array methods is "implementation-dependent"
when used with a Host object and IE throws errors.

>
> I believe this would be handled using the Array.filter() method, with a
> callback that checks if the selector matches the element, as Jonas pointed
> out:

Implementation dependent. Doesn't work in IE. Script Error: "JScript
Object Expected"

Garrett

Received on Monday, 28 September 2009 03:30:22 UTC