W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: QSA, the problem with ":scope", and naming

From: Alex Russell <slightlyoff@google.com>
Date: Thu, 20 Oct 2011 11:39:23 +0100
Message-ID: <CANr5HFUdSfdbAeR=_LmO+CgP1OzQ5GJEH8tKY+xso6cJxs5ABA@mail.gmail.com>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Cc: Webapps WG <public-webapps@w3.org>, Yehuda Katz <wycats@gmail.com>, John Resig <jeresig@gmail.com>, Paul Irish <paulirish@google.com>
On Wed, Oct 19, 2011 at 7:01 PM, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:
> On 2011-10-19 16:08, Alex Russell wrote:
>>
>> On Wed, Oct 19, 2011 at 1:54 PM, Lachlan Hunt<lachlan.hunt@lachy.id.au>
>>  wrote:
>>>
>>> I have attempted to address this problem before and the algorithm for
>>> parsing a *scoped selector string* (basically what you're calling a
>>> rootedSelector) existed in an old draft [1].
>>>
>>> That draft also allowed the flexibility of including an explicit :scope
>>> pseudo-class in the selector, which allows for conditional expressions to
>>> be
>>> built into the selector itself that can be used to check the state of the
>>> scope element or any of its ancestors.
>>
>> We could accomodate that by looking at the passed selector and trying
>> to determine if it includes a ":scope" term. If so, avoid prefixing.
>
> Yes, that's exactly what the draft specified.

Great! So if we specify this behavior for .find() too, I think we're
in good shape.

>> That'd allow this sort of flexibility for folks who want to write
>> things out long-hand or target the scope root in the selector,
>> possibly returning itself.
>
> I don't see a use case for wanting the proposed method to be able to return
> the element itself.  The case where it's useful for elements matching :scope
> to be the subject of a selector is where you're trying to filter a list of
> elements.
>
> e.g.
>  document.querySelectorAll(".foo:scope", list);
>  // Returns all elements from list that match.
>
> But this wouldn't make sense
>
>  el.find(".foo:scope") // Return itself if it matches.

Ok, I'm fine with not allowing that.

> That result seems effectively like a less efficient boolean check that is
> already handled by el.matchesSelector(".foo").

"matchesSelector"...really? We've gotta get a better name for that = )

>> I''d also support a resolution for this sort of power-tool that
>> forces people to use document.qsa("...",scopeEl) to get at that sort
>> of thing.
>
> If there was no special handling to check for an explicit :scope, that would
> mean that any selector that does include :scope explicitly would not match
> anything at all.
>
> e.g. el.findAll(":scope>p");

yeah, that occurred to me after sending the last mail.

> That would be equivalent to:
>
>  document.querySelectorAll(":scope :scope>p", el);
>
> Which won't match anything.
>
> That might keep things simpler from an implementation perspective and
> doesn't sacrifice any functionality being requested.

Eh, I'm not sure it's sane though. Putting in checking for :scope in
the selector and not prefixing if it occurs seems the only reasonable
thing. There's a corner case I haven't formed an opinion on though:

   el.find("div span :scope .whatevs");

...does what? I think it's an error. ":scope" will need to occur in
the first term or not at all for .find().

> --
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/
>
Received on Thursday, 20 October 2011 10:40:28 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT