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

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 matchesSel

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 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()

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 wrote: > On 2011-11-24 00:52, Yehuda Katz wrote: >> >> On Wed, Nov 23, 2011 at 2:38 PM, Sean Hogan wrote: >>> >>> The alternative option (find / findAll / matches can accept explicit >>> :scope, but will otherwise imply :scope) seems to be where all th

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

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)

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, r

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. Tha

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. Th

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

On 25/11/11 12:21 PM, Boris Zbarsky wrote: On 11/24/11 7:07 PM, Sean Hogan wrote: 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) That's a use case passing in a

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

On Thu, Nov 24, 2011 at 3:19 PM, 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 straight-forward interpretation of "implies :scope unless it is > explicit" is to not expan

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 10:53 AM, Yehuda Katz wrote: >> > * 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. > > I think I

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

On 11/24/11 7:07 PM, Sean Hogan wrote: 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) That's a use case passing in an explicit reference node. If you're doing

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 eac

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 > 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 disc

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 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 / findAl

Re: Remaining Problems with Explicit :scope Switching in find/findAll (was: Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?)

Yehuda Katz (ph) 718.877.1325 On Thu, Nov 24, 2011 at 6:52 AM, Tab Atkins Jr. wrote: > On Thu, Nov 24, 2011 at 12:50 AM, Lachlan Hunt > wrote: > > On 2011-11-24 00:52, Yehuda Katz wrote: > >> > >> On Wed, Nov 23, 2011 at 2:38 PM, Sean Hogan > >> wrote: > >>> > >>> The alternative option (find

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() j

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 wrote: > On 2011-11-24 00:52, Yehuda Katz wrote: >> >> On Wed, Nov 23, 2011 at 2:38 PM, Sean Hogan >>  wrote: >>> >>> The alternative option (find / findAll / matches can accept explicit >>> :scope, but will otherwise imply :scope) seems to be where a

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

On Thu, Nov 24, 2011 at 12:46 AM, 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 :s

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 Hogan 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/

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 j

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 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

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 :scop

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 wrote: > On Tue, Nov 22, 2011 at 12:19 AM, Yehuda Katz wrote: > > I like .is, the name jQuery uses for this purpose. Any reason not to go >

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 inv

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 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 e

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

On Tue, Nov 22, 2011 at 12:19 AM, Yehuda Katz 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

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 wrote: > On Tue, Nov 22, 2011 at 10:24 AM, Ojan Vafai wrote: > > On Tue, Nov 22, 2011 at 10:04 AM, Boris Zbarsky > 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

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 wrote: > On Tue, Nov 22, 2011 at 10:04 AM, Boris Zbarsky 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 po

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 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 propertie

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

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 wrote: > On 11/21/11 9:58 PM, Ojan Vafai wrote: > >> I think this is

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

On Tue, Nov 22, 2011 at 12:18 AM, Yehuda Katz wrote: > Yehuda Katz > (ph) 718.877.1325 > > > On Tue, Nov 22, 2011 at 12:14 AM, Roland Steiner > wrote: >> >> On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wrote: >>> >>> Yehuda Katz >>> (ph) 718.877.1325 >>> >>> >>> On Mon, Nov 21, 2011 at 8:34 AM, Bo

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 finit

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

On 2011-11-21 16:22, Boris Zbarsky wrote: What's the current state of matchesSelector? Are we confident enough in the name and such to unprefix it? 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

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

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 > wrote: Yehuda Katz (ph) 718.877.1325 On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky mailto:bzbar...@mit.edu>> wrote: O

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 > wrote: Yehuda Katz (ph) 718.877.1325 On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky mailto:bzbar...@mit.edu>> wrote: On 11/21/11 11:31 AM, Tab Atkins Jr. wrot

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wrote: > > Yehuda Katz > (ph) 718.877.1325 > > > On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky wrote: > >> On 11/21/11 11:31 AM, Tab Atkins Jr. wrote: >> >>> 1) Make sense. 2) Not break existing content. 3) Be short. >>> >>> .matches

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 wrote: > On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wrote: > >> >> Yehuda Katz >> (ph) 718.877.1325 >> >> >> On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky wrote: >> >>> On 11/21/11 11:31 AM, Tab Atkins Jr. wrote:

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 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 reas

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

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 t

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. Element

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 Zbarsky 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 th

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

On Mon, Nov 21, 2011 at 8:54 PM, Tab Atkins Jr. wrote: > You're not misunderstanding, but you're wrong.  ^_^  The element > itself is put in the lookup chain before document.  See this testcase: > > > foo > > (namespaceURI was the first property I could think of that's on > Element but not Docume

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

On Mon, Nov 21, 2011 at 5:31 PM, Aryeh Gregor wrote: > On Mon, Nov 21, 2011 at 11:34 AM, Boris Zbarsky 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 Elem

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

On Mon, Nov 21, 2011 at 11:34 AM, Boris Zbarsky 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?

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 8: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 Zbarsky  wrote: >>> >>> What's the current state of matchesSelector?  Are we confident enough in >>> the >>> name and such to unprefix it? >> >> I think

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 Zbarsky 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 be

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

On Mon, Nov 21, 2011 at 7:22 AM, Boris Zbarsky 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 h

[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