Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
Yehuda Katz (ph) 718.877.1325 On Fri, Nov 25, 2011 at 7:49 AM, William Edney bed...@technicalpursuit.comwrote: All - I'm going to throw my 2 cents in here and say that, whatever ends up happening with scoping, that the equivalent of the current querySelector()/querySelectorAll() should be named matchesSelector(). I'd be ok with querySelector/querySelectorAll/matchesSelector and find/findAll/matches As I have said, I personally consider qS/qSA to be implementation mistakes and would like to see find and findAll replace querySelector[All] in all cases, so maybe we don't need a matchesSelector then? As a longtime Web developer (and trainer of other Web developers) it is important to me to have consistency in naming above all else. JS libraries can always alias / wrap these names should they so desire. Name shortening has already been occurring... if we had followed 'old W3C DOM-style naming', querySelectorAll() would've been 'documentGetElementsBySelector()'. Providing a balance between short names and descriptive names is important. One of the things that drives me nuts about the (non-standard) 'document.evaluate()' call (exists on FF / Webkit to query using XPath), is that it is not explicit enough... 'evaluate' what? JS? XPath? CSS? While I don't disagree that shorter names could've been chosen all of those years ago, as Austin Powers would say, That train has sailed, baby... Cheers, - BIll On Nov 25, 2011, at 8:04 AM, Sean Hogan wrote: On 25/11/11 6:49 PM, Lachlan Hunt wrote: On 2011-11-25 01:07, Sean Hogan wrote: On 24/11/11 7:46 PM, Lachlan Hunt wrote: On 2011-11-23 23:38, Sean Hogan wrote: - If you want to use selectors with :scope implied at the start of each selector in the selector list (as most js libs currently do) then you use find / findAll / matches. The matches method will not change behaviour depending on whether or not there is an explicit :scope because it is always evaluated in the context of the entire tree. There is never an implied :scope inserted into the selector, so there will not be two alternative matches methods. If and when there is a need for a matching method that does imply :scope (which I provided a use-case for in http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0342.html) then it could be called matches(). Oh, it wasn't clear that you were talking about a case involving explicit reference nodes before. But adding two separate methods that are only subtly different would add more complexity for authors, since the difference will not always be obvious where there is no explicit reference nodes supplied and they may get them confused. In fact, with a method that always prepends :scope, it could result in an unexpected result in some cases: e.g. root.matches(html.foo); root.matchesSelector(html.foo); These aren't obviously different, but when you consider that the first would always prepend :scope under your proposal, the first would unexpectedly return false, since it's equivalent to: root.matchesSelector(:scope html.foo); This would happen whether the root element is the root of the document, or the root of a disconnected tree. We could instead address your use case by implying :scope if a refElement or refNodes is supplied. That way, if the author calls .matches() without any refNodes, they get the expected result with no implied :scope. If they do supply refNodes, and there is no explicit :scope, then imply :scope at the beginning. This approach would be completely backwards compatible with the existing implementations, as nothing changes until refNodes/refElement and :scope are supported. You mentioned this before, but anyway: el.matches(div span) - ok el.matches( div span) - throws, because no :scope implied el.matches(div :scope span) - ok, but can't match anything el.matches( div span, refNode) - ok el.matches(div :scope span, refNode) - ok el.matches(div span, refNode) - what does this do? How do you know that the intention isn't to just ignore the refNode if there is no explicit :scope? I guess if you wanted this last behavior, you could call something like /:scope\b/.test(selector) before-hand and if it is false then not pass the refNode to matches(). I'm not sure if there are other problematic cases. Sean
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
so maybe we don't need a matchesSelector then? We totally need a matchesSelector. It's perfect for event delegation. In Diego Perini's NWMatcher his `match` method is what drives the lib. https://github.com/dperini/nwmatcher/blob/master/src/nwmatcher-base.js#L391 Though he avoids the matchesSelector API at the moment because the cost of testing/avoiding cross-browser bugs kills any perf gains. https://github.com/dperini/nwmatcher/commit/10a48ac54c3673c125c540447bb74c75cd1a9ed4 -JDD On Tue, Nov 29, 2011 at 10:26 PM, Yehuda Katz wyc...@gmail.com wrote: Yehuda Katz (ph) 718.877.1325 On Fri, Nov 25, 2011 at 7:49 AM, William Edney bed...@technicalpursuit.com wrote: All - I'm going to throw my 2 cents in here and say that, whatever ends up happening with scoping, that the equivalent of the current querySelector()/querySelectorAll() should be named matchesSelector(). I'd be ok with querySelector/querySelectorAll/matchesSelector and find/findAll/matches As I have said, I personally consider qS/qSA to be implementation mistakes and would like to see find and findAll replace querySelector[All] in all cases, so maybe we don't need a matchesSelector then? As a longtime Web developer (and trainer of other Web developers) it is important to me to have consistency in naming above all else. JS libraries can always alias / wrap these names should they so desire. Name shortening has already been occurring... if we had followed 'old W3C DOM-style naming', querySelectorAll() would've been 'documentGetElementsBySelector()'. Providing a balance between short names and descriptive names is important. One of the things that drives me nuts about the (non-standard) 'document.evaluate()' call (exists on FF / Webkit to query using XPath), is that it is not explicit enough... 'evaluate' what? JS? XPath? CSS? While I don't disagree that shorter names could've been chosen all of those years ago, as Austin Powers would say, That train has sailed, baby... Cheers, - BIll On Nov 25, 2011, at 8:04 AM, Sean Hogan wrote: On 25/11/11 6:49 PM, Lachlan Hunt wrote: On 2011-11-25 01:07, Sean Hogan wrote: On 24/11/11 7:46 PM, Lachlan Hunt wrote: On 2011-11-23 23:38, Sean Hogan wrote: - If you want to use selectors with :scope implied at the start of each selector in the selector list (as most js libs currently do) then you use find / findAll / matches. The matches method will not change behaviour depending on whether or not there is an explicit :scope because it is always evaluated in the context of the entire tree. There is never an implied :scope inserted into the selector, so there will not be two alternative matches methods. If and when there is a need for a matching method that does imply :scope (which I provided a use-case for in http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0342.html) then it could be called matches(). Oh, it wasn't clear that you were talking about a case involving explicit reference nodes before. But adding two separate methods that are only subtly different would add more complexity for authors, since the difference will not always be obvious where there is no explicit reference nodes supplied and they may get them confused. In fact, with a method that always prepends :scope, it could result in an unexpected result in some cases: e.g. root.matches(html.foo); root.matchesSelector(html.foo); These aren't obviously different, but when you consider that the first would always prepend :scope under your proposal, the first would unexpectedly return false, since it's equivalent to: root.matchesSelector(:scope html.foo); This would happen whether the root element is the root of the document, or the root of a disconnected tree. We could instead address your use case by implying :scope if a refElement or refNodes is supplied. That way, if the author calls .matches() without any refNodes, they get the expected result with no implied :scope. If they do supply refNodes, and there is no explicit :scope, then imply :scope at the beginning. This approach would be completely backwards compatible with the existing implementations, as nothing changes until refNodes/refElement and :scope are supported. You mentioned this before, but anyway: el.matches(div span) - ok el.matches( div span) - throws, because no :scope implied el.matches(div :scope span) - ok, but can't match anything el.matches( div span, refNode) - ok el.matches(div :scope span, refNode) - ok el.matches(div span, refNode) - what does this do? How do you know that the intention isn't to just ignore the refNode if there is no explicit :scope? I guess if you wanted this last behavior, you could call something like /:scope\b/.test(selector) before-hand and if it is false then not pass the refNode to matches(). I'm not sure if there are other
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
Yehuda Katz (ph) 718.877.1325 On Tue, Nov 29, 2011 at 11:06 PM, John-David Dalton john.david.dal...@gmail.com wrote: so maybe we don't need a matchesSelector then? We totally need a matchesSelector. It's perfect for event delegation. In Diego Perini's NWMatcher his `match` method is what drives the lib. https://github.com/dperini/nwmatcher/blob/master/src/nwmatcher-base.js#L391 I totally agree that we need the feature. This discussion was only about what to name it. The matchesSelector name fits better with querySelectorAll, while bare matches fits with the proposed find/findAll (which would be properly scoped). Since I'm in favor of the find[All] APIs, I am also in favor of the matches name :) Though he avoids the matchesSelector API at the moment because the cost of testing/avoiding cross-browser bugs kills any perf gains. https://github.com/dperini/nwmatcher/commit/10a48ac54c3673c125c540447bb74c75cd1a9ed4 -JDD On Tue, Nov 29, 2011 at 10:26 PM, Yehuda Katz wyc...@gmail.com wrote: Yehuda Katz (ph) 718.877.1325 On Fri, Nov 25, 2011 at 7:49 AM, William Edney bed...@technicalpursuit.com wrote: All - I'm going to throw my 2 cents in here and say that, whatever ends up happening with scoping, that the equivalent of the current querySelector()/querySelectorAll() should be named matchesSelector(). I'd be ok with querySelector/querySelectorAll/matchesSelector and find/findAll/matches As I have said, I personally consider qS/qSA to be implementation mistakes and would like to see find and findAll replace querySelector[All] in all cases, so maybe we don't need a matchesSelector then? As a longtime Web developer (and trainer of other Web developers) it is important to me to have consistency in naming above all else. JS libraries can always alias / wrap these names should they so desire. Name shortening has already been occurring... if we had followed 'old W3C DOM-style naming', querySelectorAll() would've been 'documentGetElementsBySelector()'. Providing a balance between short names and descriptive names is important. One of the things that drives me nuts about the (non-standard) 'document.evaluate()' call (exists on FF / Webkit to query using XPath), is that it is not explicit enough... 'evaluate' what? JS? XPath? CSS? While I don't disagree that shorter names could've been chosen all of those years ago, as Austin Powers would say, That train has sailed, baby... Cheers, - BIll On Nov 25, 2011, at 8:04 AM, Sean Hogan wrote: On 25/11/11 6:49 PM, Lachlan Hunt wrote: On 2011-11-25 01:07, Sean Hogan wrote: On 24/11/11 7:46 PM, Lachlan Hunt wrote: On 2011-11-23 23:38, Sean Hogan wrote: - If you want to use selectors with :scope implied at the start of each selector in the selector list (as most js libs currently do) then you use find / findAll / matches. The matches method will not change behaviour depending on whether or not there is an explicit :scope because it is always evaluated in the context of the entire tree. There is never an implied :scope inserted into the selector, so there will not be two alternative matches methods. If and when there is a need for a matching method that does imply :scope (which I provided a use-case for in http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0342.html) then it could be called matches(). Oh, it wasn't clear that you were talking about a case involving explicit reference nodes before. But adding two separate methods that are only subtly different would add more complexity for authors, since the difference will not always be obvious where there is no explicit reference nodes supplied and they may get them confused. In fact, with a method that always prepends :scope, it could result in an unexpected result in some cases: e.g. root.matches(html.foo); root.matchesSelector(html.foo); These aren't obviously different, but when you consider that the first would always prepend :scope under your proposal, the first would unexpectedly return false, since it's equivalent to: root.matchesSelector(:scope html.foo); This would happen whether the root element is the root of the document, or the root of a disconnected tree. We could instead address your use case by implying :scope if a refElement or refNodes is supplied. That way, if the author calls .matches() without any refNodes, they get the expected result with no implied :scope. If they do supply refNodes, and there is no explicit :scope, then imply :scope at the beginning. This approach would be completely backwards compatible with the existing implementations, as nothing changes until refNodes/refElement and :scope are supported. You mentioned this before, but anyway: el.matches(div span) - ok
Re: Remaining Problems with Explicit :scope Switching in find/findAll (was: Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?)
On Thursday, November 24, 2011, Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2011-11-24 00:52, Yehuda Katz wrote: On Wed, Nov 23, 2011 at 2:38 PM, Sean Hoganshogu...@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(:scopediv); find(body.foo :scopediv); * 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); Here is what I sent to the list on Nov 10th. Though it didn't get archived so maybe it didn't go through properly: 1. Start with an empty list 2. Skip any whitespace at the beginning of the string. 3. If the next character is a , a + or a ~, insert a simple selector[1] containing just the :scope pseudo selector at the beginning of the selector. 4. Parse as a selector[1]. If there's a parse error throw an SyntaxError exception. 5. If during parsing a :scope pseudo class was parsed, and if a :scope pseudo selector was added in step 2, throw a SyntaxError exception. 6. If during parsing no :scope pseudo class was parsed, and if no :scope pseudo selector was added in step 2, add a simple selector containing just the :scope pseudo class to the beginning of the list, and use a descendant selector as combinator to the rest of the selector. 7. Add selector to the end of list created in step 1. 8. If, after skipping any whitespace, the next character is a comma, skip the comma and go to step 2. The resulting selector list is evaluated against the document node, but with :scope matching the node that .find/.findAll was called on. .findAll returns all nodes which match the selector in document order. .find returns the first node in the list of nodes that .findAll returns, or null if the list is empty. The reason I suggested to throw in step 5 was that such a selector would never match anything and so must be a bug. But maybe that isn't the case for /for/. More below. * 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) Can this expression ever match anything if we prepend :scope? Would simply removing step 5 above make the steps work for this case too? / Jonas
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 2011-11-25 00:19, Sean Hogan wrote: This has been raised before, but I'll restate it here. How should the selector be expanded in elt.findAll(div span, div :scope span)? The implication of :scope has to be done on a per complex selector basis, rather than applied to the entire list. That would be equivalent to: elt.findAll(:scope div span, div :scope span) If this isn't to throw an error then a more complex definition is required which can apply a different rule for implying :scope in different parts of the selector argument. This is sure to be confusing for anyone reading the code. Selectors in selector lists are always independent of each other, so authors who use a selector list would likely assume that one doesn't affect how another in the list matches. It would seem far more confusing for authors to do it using the other alternatives. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 26/11/11 12:00 AM, Lachlan Hunt wrote: On 2011-11-25 00:19, Sean Hogan wrote: This has been raised before, but I'll restate it here. How should the selector be expanded in elt.findAll(div span, div :scope span)? The implication of :scope has to be done on a per complex selector basis, rather than applied to the entire list. That would be equivalent to: elt.findAll(:scope div span, div :scope span) If this isn't to throw an error then a more complex definition is required which can apply a different rule for implying :scope in different parts of the selector argument. This is sure to be confusing for anyone reading the code. Selectors in selector lists are always independent of each other, so authors who use a selector list would likely assume that one doesn't affect how another in the list matches. It would seem far more confusing for authors to do it using the other alternatives. Discussion on this list has indicated that allowing explicit :scope in findAll() is confusing, which-ever definition is used. OTOH, there has been little or no confusion about how findAll() would behave if :scope is always implied. Do you expect the general web-dev community to be different?
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 25/11/11 6:49 PM, Lachlan Hunt wrote: On 2011-11-25 01:07, Sean Hogan wrote: On 24/11/11 7:46 PM, Lachlan Hunt wrote: On 2011-11-23 23:38, Sean Hogan wrote: - If you want to use selectors with :scope implied at the start of each selector in the selector list (as most js libs currently do) then you use find / findAll / matches. The matches method will not change behaviour depending on whether or not there is an explicit :scope because it is always evaluated in the context of the entire tree. There is never an implied :scope inserted into the selector, so there will not be two alternative matches methods. If and when there is a need for a matching method that does imply :scope (which I provided a use-case for in http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0342.html) then it could be called matches(). Oh, it wasn't clear that you were talking about a case involving explicit reference nodes before. But adding two separate methods that are only subtly different would add more complexity for authors, since the difference will not always be obvious where there is no explicit reference nodes supplied and they may get them confused. In fact, with a method that always prepends :scope, it could result in an unexpected result in some cases: e.g. root.matches(html.foo); root.matchesSelector(html.foo); These aren't obviously different, but when you consider that the first would always prepend :scope under your proposal, the first would unexpectedly return false, since it's equivalent to: root.matchesSelector(:scope html.foo); This would happen whether the root element is the root of the document, or the root of a disconnected tree. We could instead address your use case by implying :scope if a refElement or refNodes is supplied. That way, if the author calls .matches() without any refNodes, they get the expected result with no implied :scope. If they do supply refNodes, and there is no explicit :scope, then imply :scope at the beginning. This approach would be completely backwards compatible with the existing implementations, as nothing changes until refNodes/refElement and :scope are supported. You mentioned this before, but anyway: el.matches(div span) - ok el.matches( div span) - throws, because no :scope implied el.matches(div :scope span) - ok, but can't match anything el.matches( div span, refNode) - ok el.matches(div :scope span, refNode) - ok el.matches(div span, refNode) - what does this do? How do you know that the intention isn't to just ignore the refNode if there is no explicit :scope? I guess if you wanted this last behavior, you could call something like /:scope\b/.test(selector) before-hand and if it is false then not pass the refNode to matches(). I'm not sure if there are other problematic cases. Sean
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
All - I'm going to throw my 2 cents in here and say that, whatever ends up happening with scoping, that the equivalent of the current querySelector()/querySelectorAll() should be named matchesSelector(). As a longtime Web developer (and trainer of other Web developers) it is important to me to have consistency in naming above all else. JS libraries can always alias / wrap these names should they so desire. Name shortening has already been occurring... if we had followed 'old W3C DOM-style naming', querySelectorAll() would've been 'documentGetElementsBySelector()'. Providing a balance between short names and descriptive names is important. One of the things that drives me nuts about the (non-standard) 'document.evaluate()' call (exists on FF / Webkit to query using XPath), is that it is not explicit enough... 'evaluate' what? JS? XPath? CSS? While I don't disagree that shorter names could've been chosen all of those years ago, as Austin Powers would say, That train has sailed, baby... Cheers, - BIll On Nov 25, 2011, at 8:04 AM, Sean Hogan wrote: On 25/11/11 6:49 PM, Lachlan Hunt wrote: On 2011-11-25 01:07, Sean Hogan wrote: On 24/11/11 7:46 PM, Lachlan Hunt wrote: On 2011-11-23 23:38, Sean Hogan wrote: - If you want to use selectors with :scope implied at the start of each selector in the selector list (as most js libs currently do) then you use find / findAll / matches. The matches method will not change behaviour depending on whether or not there is an explicit :scope because it is always evaluated in the context of the entire tree. There is never an implied :scope inserted into the selector, so there will not be two alternative matches methods. If and when there is a need for a matching method that does imply :scope (which I provided a use-case for in http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0342.html) then it could be called matches(). Oh, it wasn't clear that you were talking about a case involving explicit reference nodes before. But adding two separate methods that are only subtly different would add more complexity for authors, since the difference will not always be obvious where there is no explicit reference nodes supplied and they may get them confused. In fact, with a method that always prepends :scope, it could result in an unexpected result in some cases: e.g. root.matches(html.foo); root.matchesSelector(html.foo); These aren't obviously different, but when you consider that the first would always prepend :scope under your proposal, the first would unexpectedly return false, since it's equivalent to: root.matchesSelector(:scope html.foo); This would happen whether the root element is the root of the document, or the root of a disconnected tree. We could instead address your use case by implying :scope if a refElement or refNodes is supplied. That way, if the author calls .matches() without any refNodes, they get the expected result with no implied :scope. If they do supply refNodes, and there is no explicit :scope, then imply :scope at the beginning. This approach would be completely backwards compatible with the existing implementations, as nothing changes until refNodes/refElement and :scope are supported. You mentioned this before, but anyway: el.matches(div span) - ok el.matches( div span) - throws, because no :scope implied el.matches(div :scope span) - ok, but can't match anything el.matches( div span, refNode) - ok el.matches(div :scope span, refNode) - ok el.matches(div span, refNode) - what does this do? How do you know that the intention isn't to just ignore the refNode if there is no explicit :scope? I guess if you wanted this last behavior, you could call something like /:scope\b/.test(selector) before-hand and if it is false then not pass the refNode to matches(). I'm not sure if there are other problematic cases. Sean
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 2011-11-23 23:38, Sean Hogan wrote: Are there any issues with: - If you want to use selectors with explicit :scope then you use querySelector / querySelectorAll / matchesSelector. - If you want to use selectors with :scope implied at the start of each selector in the selector list (as most js libs currently do) then you use find / findAll / matches. The matches method will not change behaviour depending on whether or not there is an explicit :scope because it is always evaluated in the context of the entire tree. There is never an implied :scope inserted into the selector, so there will not be two alternative matches methods. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Remaining Problems with Explicit :scope Switching in find/findAll (was: Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?)
On 2011-11-24 00:52, Yehuda Katz wrote: On Wed, Nov 23, 2011 at 2:38 PM, Sean Hoganshogu...@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(:scopediv); find(body.foo :scopediv); * 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/
Re: Remaining Problems with Explicit :scope Switching in find/findAll (was: Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?)
On Thu, Nov 24, 2011 at 12:50 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2011-11-24 00:52, Yehuda Katz wrote: On Wed, Nov 23, 2011 at 2:38 PM, Sean Hoganshogu...@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(:scopediv); find(body.foo :scopediv); Anywhere within the selector. * 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? Yes, I believe so. The first matches the whole document except for the scoping element. The second matches only the scoping element. * If using an explicit :scope, can it match itself? find(:scope) // Return null or the element itself? Yes, because selectors with an explicit scope are evaluated against the whole document. (Selectors with an implicit scope are too, theoretically, though implementations can optimize.) That example returns 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); Yes. * 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) This is equivalent to prepending :scope to the selector, and evaluating it against the whole document. In other words, it finds a span that is preceded by the scope which is immediately preceded by an input which is referenced by a label which is a child of the scope. So, the rules end up being very simple. find always evaluates against the whole document. If one of the selectors starts with a combinator or doesn't contain a :scope pseudoclass somewhere in it, :scope is prepended to it. That's it. With this, we make the most common cases (searching descendants/siblings) easy, while making the global case *also* easy. There's a bit of intent-guessing when :scope is used in an indirect way, but I believe it's better to err on the side of simplicity and consistency there. ~TJ
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 11/23/11 5:38 PM, Sean Hogan wrote: - If you want to use selectors with :scope implied at the start of each selector in the selector list (as most js libs currently do) then you use find / findAll / matches. I'm not sure that for matches() the :scope thing is all that relevant. :matches() just returns a boolean for whether the |this| it's invoked on matches the selector. The only reason one would ever use :scope in there at all is if one provides an explicit list of reference nodes, right? In particular, the assumption is that the selector passed in would obviously be allowed to match ancestor nodes of |this| for parts of it, since otherwise there is no point, right? No one would expect foo.matches(div *); to always return false; you would expect it to return true if |foo| has an _ancestor_ matching div. Similarly, no one would expect this: foo.matchs( div); to do much of anything, I would think. Or am I wrong on that? Am I just missing something here? -Boris
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
Yehuda Katz (ph) 718.877.1325 On Thu, Nov 24, 2011 at 9:47 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/23/11 5:38 PM, Sean Hogan wrote: - If you want to use selectors with :scope implied at the start of each selector in the selector list (as most js libs currently do) then you use find / findAll / matches. I'm not sure that for matches() the :scope thing is all that relevant. :matches() just returns a boolean for whether the |this| it's invoked on matches the selector. The only reason one would ever use :scope in there at all is if one provides an explicit list of reference nodes, right? In particular, the assumption is that the selector passed in would obviously be allowed to match ancestor nodes of |this| for parts of it, since otherwise there is no point, right? No one would expect foo.matches(div *); to always return false; you would expect it to return true if |foo| has an _ancestor_ matching div. Similarly, no one would expect this: foo.matchs( div); to do much of anything, I would think. Or am I wrong on that? To my ignorant eyes, you seem correct. Am I just missing something here? -Boris
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 24/11/11 10:52 AM, Yehuda Katz wrote: Yehuda Katz (ph) 718.877.1325 On Wed, Nov 23, 2011 at 2:38 PM, Sean Hogan shogu...@westnet.com.au mailto:shogu...@westnet.com.au wrote: On 23/11/11 12:17 AM, Boris Zbarsky wrote: On 11/22/11 6:50 AM, Lachlan Hunt wrote: Last time we had this discussion, you had a desire to keep the name prefixed until the refNodes and :scope stuff was implemented [1]. What's the status on that now? The status is that I've given up on the :scope discussion reaching a conclusion in finite time (esp. because it sounds like people would like to change what it means depending on the name of the function being called) and would be quite happy to ship an implementation that only takes one argument. Web pages can use .length on the function to detect support for the two-argument version if that ever happens. Are there any issues with: - If you want to use selectors with explicit :scope then you use querySelector / querySelectorAll / matchesSelector. - If you want to use selectors with :scope implied at the start of each selector in the selector list (as most js libs currently do) then you use find / findAll / matches. 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? This has been raised before, but I'll restate it here. How should the selector be expanded in elt.findAll(div span, div :scope span)? The straight-forward interpretation of implies :scope unless it is explicit is to not expand this, thus: div span, div :scope span But with that interpretation elt.findAll( div span, div :scope span) will throw an error, although elt.findAll( div span); elt.findAll(div :scope span); is allowed. If this isn't to throw an error then a more complex definition is required which can apply a different rule for implying :scope in different parts of the selector argument. This is sure to be confusing for anyone reading the code. OTOH, if find / findAll always implies :scope there isn't this problem. Moreover, that is what people will expect if they are used to jQuery's find() and equivalents in other JS libs. This makes for a fairly straight-forward explanation of usage: - If you want to use selectors with explicit :scope then you use querySelector / querySelectorAll / matchesSelector. - If you want to use selectors with :scope implied at the start of each selector in the selector list (as most js libs currently do) then you use find / findAll / matches.
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 24/11/11 7:46 PM, Lachlan Hunt wrote:
On 2011-11-23 23:38, Sean Hogan wrote:
Are there any issues with:
- If you want to use selectors with explicit :scope then you use
querySelector / querySelectorAll / matchesSelector.
- If you want to use selectors with :scope implied at the start of each
selector in the selector list (as most js libs currently do) then you
use find / findAll / matches.
The matches method will not change behaviour depending on whether or
not there is an explicit :scope because it is always evaluated in the
context of the entire tree. There is never an implied :scope inserted
into the selector, so there will not be two alternative matches methods.
A matching method that doesn't imply :scope should be called
matchesSelector().
If and when there is a need for a matching method that does imply :scope
(which I provided a use-case for in
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0342.html)
then it could be called matches().
I should be able to define querySelectorAll() in terms of
matchesSelector(),
and findAll() in terms of matches().
Thus:
function querySelectorAll(selector) {
var refNode = this;
return [].filter.call(refNode.getElementsByTagName(*),
function(elt) { return elt.matchesSelector(selector, refNode); });
}
function findAll(selector) {
var refNode = this, list = [];
for (var node=refNode; node; node=node.nextSibling) {
if (node.nodeType != 1) continue;
if (node != refNode node.matches(selector, refNode))
list.push(node);
[].push.apply(list, [].filter.call(node.getElementsByTagName(*),
function(elt) { return elt.matches(selector, refNode); });
}
return list;
}
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On Thu, Nov 24, 2011 at 3:19 PM, Sean Hogan shogu...@westnet.com.au wrote: This has been raised before, but I'll restate it here. How should the selector be expanded in elt.findAll(div span, div :scope span)? The straight-forward interpretation of implies :scope unless it is explicit is to not expand this, thus: div span, div :scope span But with that interpretation elt.findAll( div span, div :scope span) will throw an error, although elt.findAll( div span); elt.findAll(div :scope span); is allowed. If this isn't to throw an error then a more complex definition is required which can apply a different rule for implying :scope in different parts of the selector argument. This is sure to be confusing for anyone reading the code. You don't need a complex definition. The rule applies per selector (to be precise, per complex selector, using current terminology. Your example shows a comma-separated *list* of selectors. Thus, :scope is prepended to the first selector, and not to the second selector. However, this is irrelevant for matches(). It doesn't need to, and shouldn't, imply :scope. ~TJ
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 2011-11-25 01:07, Sean Hogan wrote: On 24/11/11 7:46 PM, Lachlan Hunt wrote: On 2011-11-23 23:38, Sean Hogan wrote: - If you want to use selectors with :scope implied at the start of each selector in the selector list (as most js libs currently do) then you use find / findAll / matches. The matches method will not change behaviour depending on whether or not there is an explicit :scope because it is always evaluated in the context of the entire tree. There is never an implied :scope inserted into the selector, so there will not be two alternative matches methods. If and when there is a need for a matching method that does imply :scope (which I provided a use-case for in http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0342.html) then it could be called matches(). Oh, it wasn't clear that you were talking about a case involving explicit reference nodes before. But adding two separate methods that are only subtly different would add more complexity for authors, since the difference will not always be obvious where there is no explicit reference nodes supplied and they may get them confused. In fact, with a method that always prepends :scope, it could result in an unexpected result in some cases: e.g. root.matches(html.foo); root.matchesSelector(html.foo); These aren't obviously different, but when you consider that the first would always prepend :scope under your proposal, the first would unexpectedly return false, since it's equivalent to: root.matchesSelector(:scope html.foo); This would happen whether the root element is the root of the document, or the root of a disconnected tree. We could instead address your use case by implying :scope if a refElement or refNodes is supplied. That way, if the author calls .matches() without any refNodes, they get the expected result with no implied :scope. If they do supply refNodes, and there is no explicit :scope, then imply :scope at the beginning. This approach would be completely backwards compatible with the existing implementations, as nothing changes until refNodes/refElement and :scope are supported. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On Tue, Nov 22, 2011 at 12:19 AM, Yehuda Katz wyc...@gmail.com wrote: I like .is, the name jQuery uses for this purpose. Any reason not to go with it? We might want it for something else. .matches clearly sounds like it's selector-related, and I have more trouble thinking of another meaning we'd ever really want for it.
Re: Adding methods to Element.prototype WAS: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On Tue, Nov 22, 2011 at 1:04 PM, Boris Zbarsky bzbar...@mit.edu wrote: Again, some decent data on what pages actually do in on* handlers would be really good. I have no idea how to get it. :( Can't browsers add instrumentation for this? You have users who have opted in to sending anonymized data. So for each user, on a small percentage of pages, intercept all bare-name property accesses in on*. Record the property name, and which object in the scope chain it wound up resolving to. Send info back to mothership. There will be some perf impact, but it should be no big deal if you only do it a small percentage of the time for each user. Of course, it might require a bunch of work to actually code this kind of thing -- that I'm not in a position to judge. Moving forward, this kind of info-gathering will be really essential for us to figure out how we can change stuff. Right now we have to be super-conservative when making changes because we have no idea in advance what impact they'll have. This is not a good thing for the web platform, IMO. (Aside: If we're just looking at some binary question like whether a specific name like matches is doable, you should be able to do this even without user opt-in, with no privacy breach. Just send back noise with probability (n - 1)/n, and the real value with probability 1/n, for n fairly large (say 100,000). Then average all the values together, subtract (n - 1)/n times the mean of the distribution you picked the noise values from, multiply by n, and you get something very close to the true average, by the law of large numbers. E.g., if the data is a bit, send a random bit 99.999% of the time and the real value 0.001% of the time. Average all the values, subtract 0.45, multiply by 100,000, and you have roughly the true average (error bars easily calculable). But the bit sent back by any given user would yield negligible information about that user to either the browser vendor or an eavesdropper, because it's almost surely noise. The same approach would work for any value, provided you can come up with a plausible distribution for the noise -- which is almost certainly not the case for string values, say. This would all have to be reviewed by security teams, but it should be doable in principle. The advantage is your sample would actually be representative, which could be important in some cases.)
Re: Adding methods to Element.prototype WAS: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 11/23/11 10:03 AM, Aryeh Gregor wrote: Can't browsers add instrumentation for this? You have users who have opted in to sending anonymized data. So for each user, on a small percentage of pages, intercept all bare-name property accesses in on*. With enough work, this is possible. It'd involve a good deal of complexity or some perf hit, or likely both (even when not sending; there is _always_ a perf hit from having mode code in the codebase). Also, see below. This would all have to be reviewed by security teams, but it should be doable in principle. The advantage is your sample would actually be representative, which could be important in some cases.) In fact, I think it's 100% required here, I think, since a lot of the issues come from non-public applications (those behind various passwords, etc), and the audience for those is not representative. Worse yet, we may not be able to get good statistics out of any sort of statistical scheme, even if the issue would be a stop-ship issue for users. For example, something that a quarter of our users hit every week that keeps them from using a single website they rely on would probably be considered a stop-ship bug, but would be lost in the noise of all the pages the users load during a week. -Boris
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
Works for me. I can live with .matches, but .matchesSelector is too verbose. Yehuda Katz (ph) 718.877.1325 On Wed, Nov 23, 2011 at 6:39 AM, Aryeh Gregor a...@aryeh.name wrote: On Tue, Nov 22, 2011 at 12:19 AM, Yehuda Katz wyc...@gmail.com wrote: I like .is, the name jQuery uses for this purpose. Any reason not to go with it? We might want it for something else. .matches clearly sounds like it's selector-related, and I have more trouble thinking of another meaning we'd ever really want for it.
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 23/11/11 12:17 AM, Boris Zbarsky wrote: On 11/22/11 6:50 AM, Lachlan Hunt wrote: Last time we had this discussion, you had a desire to keep the name prefixed until the refNodes and :scope stuff was implemented [1]. What's the status on that now? The status is that I've given up on the :scope discussion reaching a conclusion in finite time (esp. because it sounds like people would like to change what it means depending on the name of the function being called) and would be quite happy to ship an implementation that only takes one argument. Web pages can use .length on the function to detect support for the two-argument version if that ever happens. Are there any issues with: - If you want to use selectors with explicit :scope then you use querySelector / querySelectorAll / matchesSelector. - If you want to use selectors with :scope implied at the start of each selector in the selector list (as most js libs currently do) then you use find / findAll / matches. The alternative option (find / findAll / matches can accept explicit :scope, but will otherwise imply :scope) seems to be where all the ambiguity lies. Sean
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
Yehuda Katz (ph) 718.877.1325 On Wed, Nov 23, 2011 at 2:38 PM, Sean Hogan shogu...@westnet.com.au wrote: On 23/11/11 12:17 AM, Boris Zbarsky wrote: On 11/22/11 6:50 AM, Lachlan Hunt wrote: Last time we had this discussion, you had a desire to keep the name prefixed until the refNodes and :scope stuff was implemented [1]. What's the status on that now? The status is that I've given up on the :scope discussion reaching a conclusion in finite time (esp. because it sounds like people would like to change what it means depending on the name of the function being called) and would be quite happy to ship an implementation that only takes one argument. Web pages can use .length on the function to detect support for the two-argument version if that ever happens. Are there any issues with: - If you want to use selectors with explicit :scope then you use querySelector / querySelectorAll / matchesSelector. - If you want to use selectors with :scope implied at the start of each selector in the selector list (as most js libs currently do) then you use find / findAll / matches. 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? Sean
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
Yehuda Katz (ph) 718.877.1325 On Tue, Nov 22, 2011 at 12:14 AM, Roland Steiner rolandstei...@chromium.org wrote: On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com wrote: Yehuda Katz (ph) 718.877.1325 On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/21/11 11:31 AM, Tab Atkins Jr. wrote: 1) Make sense. 2) Not break existing content. 3) Be short. .matches .is I like .is, the name jQuery uses for this purpose. Any reason not to go with it? IMHO 'is' seems awfully broad in meaning and doesn't very well indicate that the parameter should be a selector. Inasmuch I like .matches better. It's really clear in actual usage: someElement.is(div a:first-child); Also, FWIW, an 'is' attribute on elements was/is in discussion on this ML as one possibility to specify components. Cheers, - Roland
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com wrote: Yehuda Katz (ph) 718.877.1325 On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/21/11 11:31 AM, Tab Atkins Jr. wrote: 1) Make sense. 2) Not break existing content. 3) Be short. .matches .is I like .is, the name jQuery uses for this purpose. Any reason not to go with it? IMHO 'is' seems awfully broad in meaning and doesn't very well indicate that the parameter should be a selector. Inasmuch I like .matches better. Also, FWIW, an 'is' attribute on elements was/is in discussion on this ML as one possibility to specify components. Cheers, - Roland
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 22/11/11 7:14 PM, Roland Steiner wrote: On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com mailto:wyc...@gmail.com wrote: Yehuda Katz (ph) 718.877.1325 tel:718.877.1325 On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu mailto:bzbar...@mit.edu wrote: On 11/21/11 11:31 AM, Tab Atkins Jr. wrote: 1) Make sense. 2) Not break existing content. 3) Be short. .matches .is I like .is, the name jQuery uses for this purpose. Any reason not to go with it? IMHO 'is' seems awfully broad in meaning and doesn't very well indicate that the parameter should be a selector. Inasmuch I like .matches better. Also, FWIW, an 'is' attribute on elements was/is in discussion on this ML as one possibility to specify components. Funnily enough, I've just been talking to the DOM5 and DOM6 API designers and they said almost exactly the same thing.
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 11/22/11 1:56 AM, Sean Hogan wrote:
On 22/11/11 7:14 PM, Roland Steiner wrote:
On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com
mailto:wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325 tel:718.877.1325
On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu
mailto:bzbar...@mit.edu wrote:
On 11/21/11 11:31 AM, Tab Atkins Jr. wrote:
1) Make sense.
2) Not break existing content.
3) Be short.
.matches
.is
I like .is, the name jQuery uses for this purpose. Any reason not
to go with it?
IMHO 'is' seems awfully broad in meaning and doesn't very well
indicate that the parameter should be a selector. Inasmuch I like
.matches better.
Also, FWIW, an 'is' attribute on elements was/is in discussion on
this ML as one possibility to specify components.
Funnily enough, I've just been talking to the DOM5 and DOM6 API
designers and they said almost exactly the same thing.
On the the theme, Be short, are there issues with .has?
if(node.has('[role=button]')) node.is='button';
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
Complexity and discussions about combinators seem to have prevented it from
getting into any draft despite lots of +1s. It is really different from
the rest of the selectors that exist today which are optimized like crazy
so it requires more in term of implementation than most to keep performance
sane. As yet I think (for the same reasons) no one has implemented
selectors 4 subject which is simpler than :has.
On Nov 22, 2011 5:06 AM, Charles Pritchard ch...@jumis.com wrote:
**
On 11/22/11 1:56 AM, Sean Hogan wrote:
On 22/11/11 7:14 PM, Roland Steiner wrote:
On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325
On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/21/11 11:31 AM, Tab Atkins Jr. wrote:
1) Make sense.
2) Not break existing content.
3) Be short.
.matches
.is
I like .is, the name jQuery uses for this purpose. Any reason not to go
with it?
IMHO 'is' seems awfully broad in meaning and doesn't very well indicate
that the parameter should be a selector. Inasmuch I like .matches better.
Also, FWIW, an 'is' attribute on elements was/is in discussion on this
ML as one possibility to specify components.
Funnily enough, I've just been talking to the DOM5 and DOM6 API designers
and they said almost exactly the same thing.
On the the theme, Be short, are there issues with .has?
if(node.has('[role=button]')) node.is='button';
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 11/22/11 6:50 AM, Lachlan Hunt wrote: Last time we had this discussion, you had a desire to keep the name prefixed until the refNodes and :scope stuff was implemented [1]. What's the status on that now? The status is that I've given up on the :scope discussion reaching a conclusion in finite time (esp. because it sounds like people would like to change what it means depending on the name of the function being called) and would be quite happy to ship an implementation that only takes one argument. Web pages can use .length on the function to detect support for the two-argument version if that ever happens. Any obvious problems with that plan? I believe the one-argument version is pretty clear in implementation terms, except for the name bit. -Boris
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On Tue, Nov 22, 2011 at 12:18 AM, Yehuda Katz wyc...@gmail.com wrote: Yehuda Katz (ph) 718.877.1325 On Tue, Nov 22, 2011 at 12:14 AM, Roland Steiner rolandstei...@chromium.org wrote: On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com wrote: Yehuda Katz (ph) 718.877.1325 On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/21/11 11:31 AM, Tab Atkins Jr. wrote: 1) Make sense. 2) Not break existing content. 3) Be short. .matches .is I like .is, the name jQuery uses for this purpose. Any reason not to go with it? IMHO 'is' seems awfully broad in meaning and doesn't very well indicate that the parameter should be a selector. Inasmuch I like .matches better. It's really clear in actual usage: someElement.is(div a:first-child); Please don't grab is! This is the property/attribute we want to use to identify components: div is=foobarf/div ... div.is == 'foobarf' :DG Also, FWIW, an 'is' attribute on elements was/is in discussion on this ML as one possibility to specify components. Cheers, - Roland
Re: Adding methods to Element.prototype WAS: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
+ian since this wording is actually in the HTML spec. I'm not sure how exactly this should be specced. DOM4 could specify the two interfaces and HTML could use those definitions? On Mon, Nov 21, 2011 at 7:05 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/21/11 9:58 PM, Ojan Vafai wrote: I think this is the only sane solution to this problem. Lets split up the Element interface. I'm not attached to these names, but something like ElementExposed and Element. Element inherits (mixins?) ElementExposed and only the methods on ElementExposed are exposed to the on* lookup chain. This is somwhat backwards. In particular, expandos almost certainly need to be exposed on the on* lookup chain for backwards compat. So more precisely, only the properties and methods that are NOT on ElementExposed (nor on any other DOM APIs elements implement at the moment) are missing from the on* lookup chain. I agree that all new methods and properties we add should go in this set. How to structure this in spec terms is a good question. Hmmm. I wasn't thinking of expandos. We'll definitely need to keep supportting that. :( ElementExposed would have everything that is currently on the Element API and all new methods would go on Element. You could imagine that over time we could figure out the minimal set of APIs required by web compat to leave on ElementExposed and move everything else to Element. This exercise doesn't seem to be worthwhile. What would be the benefit? The fewer properties that are exposed this way, the smaller the quirk is. I was hoping that we could have a fixed small list of properties that the spec says are exposed. Maybe that's too ambitious and doesn't actually buy us much though. In fact, we should do this for form and document as well. Yes. -Boris
Re: Adding methods to Element.prototype WAS: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 11/22/11 12:57 PM, Ojan Vafai wrote: The fewer properties that are exposed this way, the smaller the quirk is. I think the problem is that from web developers point of view the quirky behavior is _not_ exposing properties. Certainly in the short term... In the long term, since we have to expose all expandos, I suspect that not exposing properties will continue to be seen as the quirky behavior. Note, by the way, that having to expose expandos (including expandos on prototypes) but not new built-in properties might make for some fun spec-work (e.g., what happens when the standard adds a property but then some page overrides it on the prototype with a different property definition: should the page-defined value be exposed?). Again, some decent data on what pages actually do in on* handlers would be really good. I have no idea how to get it. :( I was hoping that we could have a fixed small list of properties that the spec says are exposed. Maybe that's too ambitious and doesn't actually buy us much though. Given the expando situation, I'm not sure that approach works at all. :( -Boris
Re: Adding methods to Element.prototype WAS: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On Tue, Nov 22, 2011 at 10:04 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/22/11 12:57 PM, Ojan Vafai wrote: The fewer properties that are exposed this way, the smaller the quirk is. I think the problem is that from web developers point of view the quirky behavior is _not_ exposing properties. Certainly in the short term... That's true for a large percentage of developers for sure, but most web developers I've talked to about this are surprised to learn about this behavior and have never (intentionally) depended on it. In the long term, since we have to expose all expandos, I suspect that not exposing properties will continue to be seen as the quirky behavior. Note, by the way, that having to expose expandos (including expandos on prototypes) but not new built-in properties might make for some fun spec-work (e.g., what happens when the standard adds a property but then some page overrides it on the prototype with a different property definition: should the page-defined value be exposed?). Again, some decent data on what pages actually do in on* handlers would be really good. I have no idea how to get it. :( I've been trying to get some data on this, but I haven't had much success. I'll report back if I do. But even if I get data, it'll be for specific names, not a generic what do pages do in on* handlers, so it wouldn't actually help resolving this expando question. I was hoping that we could have a fixed small list of properties that the spec says are exposed. Maybe that's too ambitious and doesn't actually buy us much though. Given the expando situation, I'm not sure that approach works at all. :( Well, it would be a small list + expandos. :) -Boris
Re: Adding methods to Element.prototype WAS: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On Tue, Nov 22, 2011 at 10:24 AM, Ojan Vafai o...@chromium.org wrote: On Tue, Nov 22, 2011 at 10:04 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/22/11 12:57 PM, Ojan Vafai wrote: The fewer properties that are exposed this way, the smaller the quirk is. I think the problem is that from web developers point of view the quirky behavior is _not_ exposing properties. Certainly in the short term... That's true for a large percentage of developers for sure, but most web developers I've talked to about this are surprised to learn about this behavior and have never (intentionally) depended on it. In the long term, since we have to expose all expandos, I suspect that not exposing properties will continue to be seen as the quirky behavior. Note, by the way, that having to expose expandos (including expandos on prototypes) but not new built-in properties might make for some fun spec-work (e.g., what happens when the standard adds a property but then some page overrides it on the prototype with a different property definition: should the page-defined value be exposed?). Again, some decent data on what pages actually do in on* handlers would be really good. I have no idea how to get it. :( I've been trying to get some data on this, but I haven't had much success. I'll report back if I do. But even if I get data, it'll be for specific names, not a generic what do pages do in on* handlers, so it wouldn't actually help resolving this expando question. I was hoping that we could have a fixed small list of properties that the spec says are exposed. Maybe that's too ambitious and doesn't actually buy us much though. Given the expando situation, I'm not sure that approach works at all. :( Well, it would be a small list + expandos. :) This is a feature that is definitely causing severe pain to the platform since it's putting constraints on APIs that we can add to our main data model, the DOM. It would be really awesome if we could figure out a way to fix this. I'd say the first step would be to evaluate if we actually need expandos. And be prepared to break a few pages by removing support for them. If we can agree to do that, then it's likely that we can create a small object which forwards a short list of properties to the form element (likely including the dynamic list of form element names) and only put that object in scope. / Jonas
Re: Adding methods to Element.prototype WAS: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On Tue, Nov 22, 2011 at 4:12 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 22, 2011 at 10:24 AM, Ojan Vafai o...@chromium.org wrote: On Tue, Nov 22, 2011 at 10:04 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/22/11 12:57 PM, Ojan Vafai wrote: I was hoping that we could have a fixed small list of properties that the spec says are exposed. Maybe that's too ambitious and doesn't actually buy us much though. Given the expando situation, I'm not sure that approach works at all. :( Well, it would be a small list + expandos. :) This is a feature that is definitely causing severe pain to the platform since it's putting constraints on APIs that we can add to our main data model, the DOM. It would be really awesome if we could figure out a way to fix this. I'd say the first step would be to evaluate if we actually need expandos. And be prepared to break a few pages by removing support for them. If we can agree to do that, then it's likely that we can create a small object which forwards a short list of properties to the form element (likely including the dynamic list of form element names) and only put that object in scope. Yes! I don't know how we can test this without just pushing out a release that does this and seeing what breaks though. Ojan
[Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
What's the current state of matchesSelector? Are we confident enough in the name and such to unprefix it? -Boris
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On Mon, Nov 21, 2011 at 7:22 AM, Boris Zbarsky bzbar...@mit.edu wrote: What's the current state of matchesSelector? Are we confident enough in the name and such to unprefix it? I think that matchesSelector suffers from the same verbosity that qSA does, and would benefit from the same discussion as what has happened over .find/findAll. ~TJ
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 11/21/11 10:56 AM, Tab Atkins Jr. wrote: On Mon, Nov 21, 2011 at 7:22 AM, Boris Zbarskybzbar...@mit.edu wrote: What's the current state of matchesSelector? Are we confident enough in the name and such to unprefix it? I think that matchesSelector suffers from the same verbosity that qSA does, and would benefit from the same discussion as what has happened over .find/findAll. I was wondering about that; hence the question. Let's have this discussion right now. What name here would: 1) Make sense. 2) Not break existing content. 3) Be short. ? -Boris
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On Mon, Nov 21, 2011 at 8:23 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/21/11 10:56 AM, Tab Atkins Jr. wrote: On Mon, Nov 21, 2011 at 7:22 AM, Boris Zbarskybzbar...@mit.edu wrote: What's the current state of matchesSelector? Are we confident enough in the name and such to unprefix it? I think that matchesSelector suffers from the same verbosity that qSA does, and would benefit from the same discussion as what has happened over .find/findAll. I was wondering about that; hence the question. Let's have this discussion right now. What name here would: 1) Make sense. 2) Not break existing content. 3) Be short. .matches .is ~TJ
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 11/21/11 11:31 AM, Tab Atkins Jr. wrote: 1) Make sense. 2) Not break existing content. 3) Be short. .matches .is The sticking point here is obviously item #2. Data needed on use of matches and is as barewords in on* attributes, specifically. -Boris
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On Mon, Nov 21, 2011 at 11:34 AM, Boris Zbarsky bzbar...@mit.edu wrote: The sticking point here is obviously item #2. Data needed on use of matches and is as barewords in on* attributes, specifically. I don't follow. matchesSelector is on Element, not Node, right? Why is it relevant to on* attributes? The lookup chain is first document then window, with no elements anywhere, right? Or am I misunderstanding you? I see why new proposed methods on Node like .prepend could be an issue (although we could leave most of those off Document too, as noted). If this is a recurring problem, could we consider implementing magic so that new methods on Document (or Node) that might cause problems are ignored in on* unless you prefix with document.? So generally a bare name will check for variables on the document first and then the window, but for the magic blacklist (matches, is, whatever causes problems) it will only check the window. Obviously this is not a great solution -- but I'd really hate us to lose out on the ideal names for common methods just because of a tiny number of sites using on*. It's possible that I'm just completely not understanding what you mean here, though.
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On Mon, Nov 21, 2011 at 5:31 PM, Aryeh Gregor a...@aryeh.name wrote: On Mon, Nov 21, 2011 at 11:34 AM, Boris Zbarsky bzbar...@mit.edu wrote: The sticking point here is obviously item #2. Data needed on use of matches and is as barewords in on* attributes, specifically. I don't follow. matchesSelector is on Element, not Node, right? Why is it relevant to on* attributes? The lookup chain is first document then window, with no elements anywhere, right? Or am I misunderstanding you? I see why new proposed methods on Node like .prepend could be an issue (although we could leave most of those off Document too, as noted). If this is a recurring problem, could we consider implementing magic so that new methods on Document (or Node) that might cause problems are ignored in on* unless you prefix with document.? So generally a bare name will check for variables on the document first and then the window, but for the magic blacklist (matches, is, whatever causes problems) it will only check the window. Obviously this is not a great solution -- but I'd really hate us to lose out on the ideal names for common methods just because of a tiny number of sites using on*. It's possible that I'm just completely not understanding what you mean here, though. You're not misunderstanding, but you're wrong. ^_^ The element itself is put in the lookup chain before document. See this testcase: !DOCTYPE html button onclick=alert(namespaceURI)foo/button (namespaceURI was the first property I could think of that's on Element but not Document.) I would also *love* if it we could mitigate this in the future by requiring you to use document.* or this.* to access new stuff on the document or element, so we could stop worrying about this sort of conflict. We'd just have to define the handful of legacy properties from before this change that can still be accessed as barewords, and possibly all expandos (investigation is needed). ~TJ
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On Mon, Nov 21, 2011 at 8:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: You're not misunderstanding, but you're wrong. ^_^ The element itself is put in the lookup chain before document. See this testcase: !DOCTYPE html button onclick=alert(namespaceURI)foo/button (namespaceURI was the first property I could think of that's on Element but not Document.) Awesome. It seems on* is even more pathological than I realized. So definitely, I don't think we want to avoid adding short names to Node or Element or Document forever just because of this. If the cost is making bare name lookup in on* slightly more pathological than it already is, I don't think that's a big deal. Authors who want to preserve their sanity should already be prefixing everything with window. or document. or whatever is appropriate. Let's add .matches() and just make it not triggered as a bare name from on*.
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 22/11/11 3:23 AM, Boris Zbarsky wrote: On 11/21/11 10:56 AM, Tab Atkins Jr. wrote: On Mon, Nov 21, 2011 at 7:22 AM, Boris Zbarskybzbar...@mit.edu wrote: What's the current state of matchesSelector? Are we confident enough in the name and such to unprefix it? I think that matchesSelector suffers from the same verbosity that qSA does, and would benefit from the same discussion as what has happened over .find/findAll. I was wondering about that; hence the question. Let's have this discussion right now. What name here would: 1) Make sense. The current defined behavior of matchesSelector() goes with the behavior of querySelectorAll(), so the name seems appropriate. If find / findAll is implemented then a matches() method with corresponding behavior might be appropriate. See the discussion that started at http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0342.html Sean
Adding methods to Element.prototype WAS: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
I think this is the only sane solution to this problem. Lets split up the Element interface. I'm not attached to these names, but something like ElementExposed and Element. Element inherits (mixins?) ElementExposed and only the methods on ElementExposed are exposed to the on* lookup chain. ElementExposed would have everything that is currently on the Element API and all new methods would go on Element. You could imagine that over time we could figure out the minimal set of APIs required by web compat to leave on ElementExposed and move everything else to Element. In fact, we should do this for form and document as well. It's a nasty wart to put on the platform, but it's better than being unable to expose APIs with good names or with exposing APIs with good names and breaking existing content. Ojan On Mon, Nov 21, 2011 at 6:00 PM, Aryeh Gregor a...@aryeh.name wrote: On Mon, Nov 21, 2011 at 8:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: You're not misunderstanding, but you're wrong. ^_^ The element itself is put in the lookup chain before document. See this testcase: !DOCTYPE html button onclick=alert(namespaceURI)foo/button (namespaceURI was the first property I could think of that's on Element but not Document.) Awesome. It seems on* is even more pathological than I realized. So definitely, I don't think we want to avoid adding short names to Node or Element or Document forever just because of this. If the cost is making bare name lookup in on* slightly more pathological than it already is, I don't think that's a big deal. Authors who want to preserve their sanity should already be prefixing everything with window. or document. or whatever is appropriate. Let's add .matches() and just make it not triggered as a bare name from on*.
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 11/21/11 8:31 PM, Aryeh Gregor wrote: The lookup chain is first document then window, with no elements anywhere, right? The lookup order is the element the on* attribute is on, then the element's form if it's a form control (more or less; details are in the spec), then the document, then the window. There are also some additional complications in terms of time-invariance of the lookup chain, etc, which most browsers agree on but a few do not. If this is a recurring problem It is. could we consider implementing magic so that new methods on Document (or Node) that might cause problems are ignored in on* unless you prefix with document.? We could consider it; it would require that what goes on the scope chain of on* even handlers is some sort of proxy instead of the actual element/form/document/etc, I think... That might work, though. Would somewhat hurt performance for whatever code is inside the on* attribute itself (not including functions it calls), but that's usually not that much code, and already has a certain amount of overhead for the C++ to JS transition. Maybe this is the way to go. -Boris
Re: Adding methods to Element.prototype WAS: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 11/21/11 9:58 PM, Ojan Vafai wrote: I think this is the only sane solution to this problem. Lets split up the Element interface. I'm not attached to these names, but something like ElementExposed and Element. Element inherits (mixins?) ElementExposed and only the methods on ElementExposed are exposed to the on* lookup chain. This is somwhat backwards. In particular, expandos almost certainly need to be exposed on the on* lookup chain for backwards compat. So more precisely, only the properties and methods that are NOT on ElementExposed (nor on any other DOM APIs elements implement at the moment) are missing from the on* lookup chain. I agree that all new methods and properties we add should go in this set. How to structure this in spec terms is a good question. ElementExposed would have everything that is currently on the Element API and all new methods would go on Element. You could imagine that over time we could figure out the minimal set of APIs required by web compat to leave on ElementExposed and move everything else to Element. This exercise doesn't seem to be worthwhile. What would be the benefit? In fact, we should do this for form and document as well. Yes. -Boris
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
Yehuda Katz (ph) 718.877.1325 On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/21/11 11:31 AM, Tab Atkins Jr. wrote: 1) Make sense. 2) Not break existing content. 3) Be short. .matches .is I like .is, the name jQuery uses for this purpose. Any reason not to go with it? The sticking point here is obviously item #2. Data needed on use of matches and is as barewords in on* attributes, specifically. -Boris
