- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Thu, 24 Nov 2011 09:50:22 +0100
- To: Yehuda Katz <wycats@gmail.com>
- CC: Sean Hogan <shogun70@westnet.com.au>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
On 2011-11-24 00:52, Yehuda Katz wrote: > On Wed, Nov 23, 2011 at 2:38 PM, Sean Hogan<shogun70@westnet.com.au> wrote: >> The alternative option (find / findAll / matches can accept explicit >> :scope, but will otherwise imply :scope) seems to be where all the >> ambiguity lies. > > What exact cases are ambiguous with "find/findAll/matches can accept > explicit :scope, but will otherwise imply :scope"? The problems to be solved with automatically switching between implied and explicit :scope are basically in determining what exactly counts as an explicit :scope. The answers to each of these has is trade off between complexity and functionality, with the simplest option being always implying :scope. * Is explicit :scope allowed at the beginning of each selector? find(":scope>div"); find("body.foo :scope>div"); * Does :scope inside functional pseudo-classes count? find(":not(:scope)"); find(":matches(:scope)"); If yes, does the first match the whole document, only descendants, or descendants plus siblings? * If using an explicit :scope, can it match itself? find(":scope") // Return null or the element itself? * Is :scope always implied if it begins with an explicit combinator other than descendant, even if :scope is used elsewhere? find(">div :scope"); find("+div :scope"); find("~div :scope"); * There's also the general issue, not related to :scope, about how the reference combinator affects the range of potential matches. label.find("/for/ input") Based on the above issues, what happens in this case? foo.find(">label /for/ input+:scope~span) -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Received on Thursday, 24 November 2011 08:51:05 UTC