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

RE: Selectors: name find method and find signature

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Thu, 12 Sep 2013 16:38:56 +0000
To: Boris Zbarsky <bzbarsky@MIT.EDU>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <B4AE8F4E86E26C47AC407D49872F6F9F918CB781@BY2PRD0510MB354.namprd05.prod.outlook.com>
> And in particular, the spec as written now doesn't clearly define the behavior of query() or queryAll().  Presumably they would be defined in some generic way (such that they can run with any object as "this"), but it's not obvious what that generic way is in this case.  This seems like a general problem we'll encounter with unbranded things.  Or is Elements branded in some way?  If so, in what way?

Yeah they should work generically. That is,

var els = [document.querySelector("body"), document.querySelector("div")];
var coolThing = Elements.prototype.query.call(".cool-thing");


should work.

One idea we had for this was as outlined in the gist at [1], where they try to call some internal "[[QuerySelectorAll]]"-like method of things contained within it, and presumably blow up when someone tries to use `query` or `queryAll` on `Elements` instances that contain non-`Element`s. (But, all other array operations would work fine on such hybrids, and indeed we use that property in the gist.)

This approach would also allow element subclasses to work inside `Elements` (i.e. they would not cause blow-up). See [2] and its thread.

I doubt implementing `query` in terms of `querySelectorAll` is actually the best approach though; maybe checking for some internally-set property like [[Queryable]] or [[CanBeReferenceElementForRelativeSelector]] would be better. The same process of using @@create to set them would work.

[1]: https://gist.github.com/domenic/5864658
[2]: http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0350.html 

Received on Thursday, 12 September 2013 16:39:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:13 UTC