Re: Making selectors first-class citizens
On 9/12/13, Brian Kardell wrote:
> On Sep 12, 2013 2:16 AM, "Garrett Smith" wrote:
>>
>> FWD'ing to put my reply back on list (and to others)...
>>
>> On Sep 11, 2013 6:35 AM, Anne van Kesteren wrote:
>>
>> As far as I can tell Element.prototype.matches() is not deployed yet.
>> Should we instead make selectors first-class citizens, just like
>> regular expressions, and have
>>
>> var sel = new Selectors("i > love > selectors, so[much]")
>> sel.test(node)
>>
>> # 2007 David Anderson proposed the idea.
>>
>> That seems like a much nicer approach.
>>
>> (It also means this can be neatly defined in the Selectors
>> specification, rather than in DOM, which means less work for me. :-))
>>
>> # 2009 the API design remerged
>> http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1445.html
>>
>> # 2010 Selectors explained in an article:
>> http://www.fortybelow.ca/hosted/dhtmlkitchen/JavaScript-Query-Engines.html
>> (search Query Matching Strategy).
[...]
> I may be the only one, but... I am unsure what you are advocating here
> Garrett.
>
I have advocated and used the strategy of matching elements by
>From "Query Matching Strategy"
Most usage of queries don't allow for common traversal patterns of
finding an ancestor. Such traversal pattern is often needed when using
event delegation strategies, where the callback needs to know find an
ancestor matching a particular criteria, usually either ID, className
or tagName.
var sel = new Selector("ul.panel");
function clickCallback(ev) {
var target = DomUtils.getTarget(ev);
if(sel.test(target)) {
panelListClickHandler(ev);
}
}
For matching, sel.match(node); matchAll(node);
But el.matches() is not so good. Boolean methods should start with
'is', 'has', or 'can'. Also, the object that it is being called should
be responsible for the role of the method on it. Elements don't
"match"; selectors do.
Inre Selectors vs Selector, plural names lead to confusion (e.g.
UIEvent vs UIEvents in DOM specs). Postfixing 'List', is better. I
recently saw and commented on Elements, by suggesting ElementList.
--
Garrett
Twitter: @xkit
personx.tumblr.com
Re: Making selectors first-class citizens
On Sep 17, 2013, at 5:48 AM, Anne van Kesteren wrote: > On Mon, Sep 16, 2013 at 8:49 PM, Boris Zbarsky wrote: >> What's a new rendering engine supposed to do? Implement one of the prefixed >> versions? Break content? Implement the unprefixed version? I'd say that if >> the answer to any of those is "yes" without the spec saying so, then the >> spec is useless here. >> >> This is not an academic question, of course. > > Right, if we cannot remove the prefixed variant we'll have to > reconsider this as I said many many emails ago. I'm also curious to know whether there are enough Web content (particularly mobile) that assume the existence of *MatchesSelector or matchesSelector. If there are, we should probably stick with matchesSelector. - R. Niwa
Re: Making selectors first-class citizens
On Mon, Sep 16, 2013 at 8:49 PM, Boris Zbarsky wrote: > What's a new rendering engine supposed to do? Implement one of the prefixed > versions? Break content? Implement the unprefixed version? I'd say that if > the answer to any of those is "yes" without the spec saying so, then the > spec is useless here. > > This is not an academic question, of course. Right, if we cannot remove the prefixed variant we'll have to reconsider this as I said many many emails ago. -- http://annevankesteren.nl/
Re: Making selectors first-class citizens
On 9/16/13 5:48 PM, Tab Atkins Jr. wrote: That code isn't depending on matchesSelector, it's depending on fooMatchesSelector *or* matchesSelector. As long as the former works, it's fine - we don't need to add the latter as well. Tab, What's a new rendering engine supposed to do? Implement one of the prefixed versions? Break content? Implement the unprefixed version? I'd say that if the answer to any of those is "yes" without the spec saying so, then the spec is useless here. This is not an academic question, of course. -Boris
Re: Making selectors first-class citizens
On Mon, Sep 16, 2013 at 2:33 PM, Brian Kardell wrote: >> There are >> literally zero scripts which depend on the name "matchesSelector", >> because it's never worked anywhere. They might depend on the prefixed >> variants, but that's a separate issue to deal with. > > I think Francois shared a github search with shows almost 15,500 uses > expecting matchesSelector. I think we all agree these should work just fine > as long as prefixes remain - but that's the point... With that many, why > worry about when someone wrote their code or unprefixing or lots more > emails. Seems an acceptable amount of cruft to me in this case. Having > said that, I promise I will make no further case :) That code isn't depending on matchesSelector, it's depending on fooMatchesSelector *or* matchesSelector. As long as the former works, it's fine - we don't need to add the latter as well. ~TJ
Re: Making selectors first-class citizens
On Mon, Sep 16, 2013 at 4:29 PM, Tab Atkins Jr. wrote: > On Mon, Sep 16, 2013 at 1:05 PM, Brian Kardell wrote: > >> If they didn't support down-level browsers at all, then they're > >> already broken for a lot of users, so making them broken for a few > >> more shouldn't be a huge deal. ^_^ > > > > This seems like a cop out if there is an easy way to avoid breaking them. > > Just leaving the prefixed ones there goes a long way, but I think we've > > shown that some libs and uses either happened before the decision to > switch > > to .matches so they forward estimated that it would be .matchesSelector > and, > > people used them (or maybe they've used them before the lib was updated > > even). It seems really easy to unprefix matchesSelector, and say "see > > matches, it's an alias" and prevent breakage. If I'm alone on that, I'm > not > > going to keep beating it to death, it just seems easily forward > friendly. I > > know I've gotten calls for some mom and pop type project where I guessed > > wrong on early standards in my younger days and, well - it sucks. I'd > > rather not put anyone else through that pain unnecessarily if there is a > > simple fix. Maybe I am wrong about the level of simplicity, but - it > seems > > really bikesheddy anyway. > > Aliasing cruft is *often* very simple to add; that's not the point. > It's *cruft*, and unnecessary at that. Aliasing is sometimes a good > idea, if you have a well-supported bad name and there's a really good > alternate name you want to use which is way more consistent, etc. > This isn't the case here - you're suggesting we add an alias for a > term that *doesn't even exist on the platform yet*. I feel like you are taking it to mean that I am advocating aliasing everywhere for everything where that is not simply not my intent. I am saying in this one very particular case because of the timing of things it seems like it would be a good idea to alias and be done with it. > There are > literally zero scripts which depend on the name "matchesSelector", > because it's never worked anywhere. They might depend on the prefixed > variants, but that's a separate issue to deal with. > > I think Francois shared a github search with shows almost 15,500 uses expecting matchesSelector. I think we all agree these should work just fine as long as prefixes remain - but that's the point... With that many, why worry about when someone wrote their code or unprefixing or lots more emails. Seems an acceptable amount of cruft to me in this case. Having said that, I promise I will make no further case :) > ~TJ > -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Making selectors first-class citizens
On Mon, Sep 16, 2013 at 5:43 PM, Scott González wrote: > On Mon, Sep 16, 2013 at 5:33 PM, Brian Kardell wrote: > >> I think Francois shared a github search with shows almost 15,500 uses >> expecting matchesSelector. >> > > As is generally the case, that GitHub search returns the same code > duplicated thousands of times. From this search, it's impossible to tell > which are forks of libraries implementing a polyfill or shim, which are > projects that actually get released, which are projects that will never be > released, and which will update their dependencies in a timely fashion > (resulting in use of the proper method). It seems like a fair amount of > these are actually just a few polyfills or different versions of jQuery. > These results are also inflated by matches in source maps. > That's a good observation. I hadn't considered that. -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Making selectors first-class citizens
On Mon, Sep 16, 2013 at 5:33 PM, Brian Kardell wrote: > I think Francois shared a github search with shows almost 15,500 uses > expecting matchesSelector. > As is generally the case, that GitHub search returns the same code duplicated thousands of times. From this search, it's impossible to tell which are forks of libraries implementing a polyfill or shim, which are projects that actually get released, which are projects that will never be released, and which will update their dependencies in a timely fashion (resulting in use of the proper method). It seems like a fair amount of these are actually just a few polyfills or different versions of jQuery. These results are also inflated by matches in source maps.
RE: Making selectors first-class citizens
> Read the thread more closely - as always, we only suggest dropping > prefixed variants *if possible*. Define possible. If we add "matchesSelector" as an official alias to "matches" the same way "querySelector" and "querySelectorAll" will be aliases to "query" and "queryAll" soon, it should be possible to drop the prefixed version. This is possible, according to my definition of possible. So, the question is: do we want browser to feature "matchesSelector", "blablaMatchesSelector" or break stuff? My take would be we should prefer the former. After that, it's just an opinion, now you have it do whatever you think with it ;-)
Re: Making selectors first-class citizens
On Mon, Sep 16, 2013 at 1:05 PM, Brian Kardell wrote: >> If they didn't support down-level browsers at all, then they're >> already broken for a lot of users, so making them broken for a few >> more shouldn't be a huge deal. ^_^ > > This seems like a cop out if there is an easy way to avoid breaking them. > Just leaving the prefixed ones there goes a long way, but I think we've > shown that some libs and uses either happened before the decision to switch > to .matches so they forward estimated that it would be .matchesSelector and, > people used them (or maybe they've used them before the lib was updated > even). It seems really easy to unprefix matchesSelector, and say "see > matches, it's an alias" and prevent breakage. If I'm alone on that, I'm not > going to keep beating it to death, it just seems easily forward friendly. I > know I've gotten calls for some mom and pop type project where I guessed > wrong on early standards in my younger days and, well - it sucks. I'd > rather not put anyone else through that pain unnecessarily if there is a > simple fix. Maybe I am wrong about the level of simplicity, but - it seems > really bikesheddy anyway. Aliasing cruft is *often* very simple to add; that's not the point. It's *cruft*, and unnecessary at that. Aliasing is sometimes a good idea, if you have a well-supported bad name and there's a really good alternate name you want to use which is way more consistent, etc. This isn't the case here - you're suggesting we add an alias for a term that *doesn't even exist on the platform yet*. There are literally zero scripts which depend on the name "matchesSelector", because it's never worked anywhere. They might depend on the prefixed variants, but that's a separate issue to deal with. ~TJ
Re: Making selectors first-class citizens
On Mon, Sep 16, 2013 at 4:45 PM, François REMY < francois.remy@outlook.com> wrote: > If we add "matchesSelector" as an official alias to "matches" the same way > "querySelector" and "querySelectorAll" will be aliases to "query" and > "queryAll" soon, it should be possible to drop the prefixed version. This > is possible, according to my definition of possible. > Sorry about this being off-topic, but since query() keeps coming up as a comparison, I think this is a relevant question: query() and queryAll() are going to be aliases? I thought the new names were being created to fix the mismatch between how web developers think and how querySelector() works, specifically only matching from within the context.
Re: Making selectors first-class citizens
On Mon, Sep 16, 2013 at 1:45 PM, François REMY wrote: >> Read the thread more closely - as always, we only suggest dropping >> prefixed variants *if possible*. > > Define possible. "Can be done without too many pages breaking as a result", where "too many" is subjective. But dealing with prefixes has nothing to do with aliasing. > If we add "matchesSelector" as an official alias to "matches" the same way > "querySelector" and "querySelectorAll" will be aliases to "query" and > "queryAll" soon, it should be possible to drop the prefixed version. This is > possible, according to my definition of possible. query() isn't an alias for querySelector(). ~TJ
Re: Making selectors first-class citizens
On Mon, Sep 16, 2013 at 1:32 PM, François REMY wrote: >> Regardless of what they assumed, there's presumably a case to handle >> older browsers that don't support it at all. If the scripts guessed >> wrongly about what the unprefixed name would be, then they'll fall >> into this case anyway, which should be okay. >> >> If they didn't support down-level browsers at all, then they're >> already broken for a lot of users, so making them broken for a few >> more shouldn't be a huge deal. ^_^ > > I can't name any currently-used mobile browser that doesn't ship with a > *MatchesSelector function. The "drop it" proposal is to break code for the > sake of breaking code. Read the thread more closely - as always, we only suggest dropping prefixed variants *if possible*. ~TJ
RE: Making selectors first-class citizens
> Regardless of what they assumed, there's presumably a case to handle > older browsers that don't support it at all. If the scripts guessed > wrongly about what the unprefixed name would be, then they'll fall > into this case anyway, which should be okay. > > If they didn't support down-level browsers at all, then they're > already broken for a lot of users, so making them broken for a few > more shouldn't be a huge deal. ^_^ I can't name any currently-used mobile browser that doesn't ship with a *MatchesSelector function. The "drop it" proposal is to break code for the sake of breaking code. What is the point? We will soon have querySelector and query, and that didn't make the world fall into pieces...
Re: Making selectors first-class citizens
On Mon, Sep 16, 2013 at 1:52 PM, Scott González wrote: > On Mon, Sep 16, 2013 at 4:45 PM, François REMY > wrote: >> >> If we add "matchesSelector" as an official alias to "matches" the same way >> "querySelector" and "querySelectorAll" will be aliases to "query" and >> "queryAll" soon, it should be possible to drop the prefixed version. This is >> possible, according to my definition of possible. > > Sorry about this being off-topic, but since query() keeps coming up as a > comparison, I think this is a relevant question: > > query() and queryAll() are going to be aliases? I thought the new names were > being created to fix the mismatch between how web developers think and how > querySelector() works, specifically only matching from within the context. No, they're not aliases - I think maybe François got confused. They are indeed different functions, much closer to jQuery's .find() method. ~TJ
Re: Making selectors first-class citizens
On Mon, Sep 16, 2013 at 12:03 PM, Brian Kardell wrote: > I think the responses/questions are getting confused. I'm not sure about > others, but my position is actually not that complicated: This feature has > been out there and interoperable for quite a while - it is prefixed > everywhere and called matchesSelector. No, it's called *MatchesSelector, where * is various vendor prefixes. > Some potentially significant group > of people assumed that when it was unprefixed it would be called "matches" > and others "matchesSelector". Regardless of what they assumed, there's presumably a case to handle older browsers that don't support it at all. If the scripts guessed wrongly about what the unprefixed name would be, then they'll fall into this case anyway, which should be okay. If they didn't support down-level browsers at all, then they're already broken for a lot of users, so making them broken for a few more shouldn't be a huge deal. ^_^ ~TJ
Re: Making selectors first-class citizens
On Sep 16, 2013 3:46 PM, "Tab Atkins Jr." wrote: > > On Mon, Sep 16, 2013 at 12:03 PM, Brian Kardell wrote: > > I think the responses/questions are getting confused. I'm not sure about > > others, but my position is actually not that complicated: This feature has > > been out there and interoperable for quite a while - it is prefixed > > everywhere and called matchesSelector. > > No, it's called *MatchesSelector, where * is various vendor prefixes. > Yeah, that is more accurately what I intended to convey - the delta being the selector part. > > Some potentially significant group > > of people assumed that when it was unprefixed it would be called "matches" > > and others "matchesSelector". > > Regardless of what they assumed, there's presumably a case to handle > older browsers that don't support it at all. If the scripts guessed > wrongly about what the unprefixed name would be, then they'll fall > into this case anyway, which should be okay. > Yes, as long as prefixes stay around, and we don't change repurpose .matches for another use that's true. I thought someone suggested the later earlier in the thread(s) have to go back and look. > If they didn't support down-level browsers at all, then they're > already broken for a lot of users, so making them broken for a few > more shouldn't be a huge deal. ^_^ > This seems like a cop out if there is an easy way to avoid breaking them. Just leaving the prefixed ones there goes a long way, but I think we've shown that some libs and uses either happened before the decision to switch to .matches so they forward estimated that it would be .matchesSelector and, people used them (or maybe they've used them before the lib was updated even). It seems really easy to unprefix matchesSelector, and say "see matches, it's an alias" and prevent breakage. If I'm alone on that, I'm not going to keep beating it to death, it just seems easily forward friendly. I know I've gotten calls for some mom and pop type project where I guessed wrong on early standards in my younger days and, well - it sucks. I'd rather not put anyone else through that pain unnecessarily if there is a simple fix. Maybe I am wrong about the level of simplicity, but - it seems really bikesheddy anyway. > ~TJ
Re: Making selectors first-class citizens
On Sep 13, 2013, at 8:26 PM, Brian Kardell wrote: > > On Sep 13, 2013 4:38 PM, "Ryosuke Niwa" wrote: > > > > > > On Sep 11, 2013, at 11:54 AM, Francois Remy wrote: > > > >> For the record, I'm equally concerned about renaming `matchesSelector` > >> into `matches`. > >> > >> A lot of code now rely on a prefixed or unprefixed version of > >> `matchesSelector` as this has shipped in an interoperable fashion in all > >> browsers now. > > > > > > Which browser ships matchesSelector unprefixed? > > Neither Chrome, Firefox, nor Safari ship matchesSelector unprefixed. > > > > > > On Sep 13, 2013, at 1:12 PM, Francois Remy wrote: > > > A lot of code now rely on a prefixed or unprefixed version of > `matchesSelector` as this has shipped in an interoperable fashion in all > browsers now. > >>> > >>> > >>> Unprefixed? > >> > >> > >> Yeah. Future-proofing of existing code, mostly: > >> > >> > >> https://github.com/search?q=matchesSelector+msMatchesSelector&type=Code&ref > >> =searchresults > > > > > > That’s just broken code. One cannot speculatively rely on unprefixed DOM > > functions until they’re actually spec’ed and shiped. > > I have no sympathy or patience to maintain the backward compatibility with > > the code that has never worked. > > > > I am not really sure why you feel this way - this piece of the draft is > tremendously stable, and interoperable as anything else. > It's not interoperable at all. No vendor has ever shipped matchesSelector unprefixed as far as I know. i.e. it didn't work anywhere unless you explicitly relied upon prefixed versions. > Prefixes bound to vendors which may or may not match final and may or may not > disappear when final comes around or just whenever, in release channel is > exactly why most people are against this sort of thing now. This predates > that shift and regardless of whether we like it, stuff will break for people > who were just following examples and going by the implementation/interop and > standard perception of stability. Websites will stop working correctly - > some will never get fixed - others will waste the time of hundreds or > thousands of devs... > Anyone using the prefixed versions should have a fallback path for old browsers that doesn't support it. If some websites will break, then we'll simply keep the old prefixed version around but this is essentially each vendor's decision. Gecko might drop sooner than other vendors for example. > So.. Ok to keep prefix working in all browsers, but not just add it? For the > most part, isn't that just like an alias? > Whether a browser keeps a prefixed version working or not is each vendor's decision. Given that the unprefixed version has never worked, I don't see why we want to use the name matchesSelector as opposed to matches. - R. Niwa
Re: Making selectors first-class citizens
On Mon, Sep 16, 2013 at 2:51 PM, Ryosuke Niwa wrote: > On Sep 13, 2013, at 8:26 PM, Brian Kardell wrote: > > > On Sep 13, 2013 4:38 PM, "Ryosuke Niwa" wrote: > > > > > > On Sep 11, 2013, at 11:54 AM, Francois Remy wrote: > > > >> For the record, I'm equally concerned about renaming `matchesSelector` > into `matches`. > >> > >> A lot of code now rely on a prefixed or unprefixed version of > `matchesSelector` as this has shipped in an interoperable fashion in all > browsers now. > > > > > > Which browser ships matchesSelector unprefixed? > > Neither Chrome, Firefox, nor Safari ship matchesSelector unprefixed. > > > > > > On Sep 13, 2013, at 1:12 PM, Francois Remy wrote: > > > A lot of code now rely on a prefixed or unprefixed version of > `matchesSelector` as this has shipped in an interoperable fashion in > all > browsers now. > >>> > >>> > >>> Unprefixed? > >> > >> > >> Yeah. Future-proofing of existing code, mostly: > >> > >> > >> > https://github.com/search?q=matchesSelector+msMatchesSelector&type=Code&ref > >> =searchresults > > > > > > That’s just broken code. One cannot speculatively rely on unprefixed > DOM functions until they’re actually spec’ed and shiped. > > I have no sympathy or patience to maintain the backward compatibility > with the code that has never worked. > > > > I am not really sure why you feel this way - this piece of the draft is > tremendously stable, and interoperable as anything else. > > It's not interoperable at all. No vendor has ever shipped matchesSelector > unprefixed as far as I know. i.e. it didn't work anywhere unless you > explicitly relied upon prefixed versions. > > Prefixes bound to vendors which may or may not match final and may or may > not disappear when final comes around or just whenever, in release channel > is exactly why most people are against this sort of thing now. This > predates that shift and regardless of whether we like it, stuff will break > for people who were just following examples and going by the > implementation/interop and standard perception of stability. Websites > will stop working correctly - some will never get fixed - others will waste > the time of hundreds or thousands of devs... > > Anyone using the prefixed versions should have a fallback path for old > browsers that doesn't support it. If some websites will break, then we'll > simply keep the old prefixed version around but this is essentially each > vendor's decision. Gecko might drop sooner than other vendors for example. > > So.. Ok to keep prefix working in all browsers, but not just add it? For > the most part, isn't that just like an alias? > > Whether a browser keeps a prefixed version working or not is each vendor's > decision. Given that the unprefixed version has never worked, I don't see > why we want to use the name matchesSelector as opposed to matches. > > - R. Niwa > > I think the responses/questions are getting confused. I'm not sure about others, but my position is actually not that complicated: This feature has been out there and interoperable for quite a while - it is prefixed everywhere and called matchesSelector. Some potentially significant group of people assumed that when it was unprefixed it would be called "matches" and others "matchesSelector". Whatever we think people should do in terms of whether there is a fallback or what not, we know reality often doesn't match that - people support a certain version forward. However much we'd like people to switch, lots of websites are an investment that doesn't get revisited for a long time. Thus: 1) let's not try to repurpose matches for anything that doesn't match this signature (I thought I heard someone advocating that early on) 2) let's make sure we don't disable those prefixes and risk breaking stuff that assumed improperly ~or~ if possible - since this is so bikesheddy, let's just make an alias in the spec given the circumstances. -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Making selectors first-class citizens
On Sat, Sep 14, 2013 at 1:48 PM, Brian Kardell wrote: > Very succinctly, i am suggesting: > .matchesSector be unprefixed, .matches is an alias and docs just say "see > matchesSelector, its an alias." And no one breaks. And we avoid this in the > future by following better practices. We can decide doing that if it's actually a problem in practice. We will try to ship the plan of record first before committing to a less optimal solution. -- http://annevankesteren.nl/
Re: Making selectors first-class citizens
On Sep 14, 2013 6:07 AM, "Anne van Kesteren" wrote: > > On Sat, Sep 14, 2013 at 4:26 AM, Brian Kardell wrote: > > I am not really sure why you feel this way - this piece of the draft is > > tremendously stable, and interoperable as anything else. The decision to > > make it matches was old and popular. It's not just random joe schmoe doing > > this, it's illustrated and recommended by respected sources... For example > > http://docs.webplatform.org/wiki/dom/methods/matchesSelector > > 1) I don't think that's a respected source just yet. 2) When I search > for matchesSelector on Google I get > https://developer.mozilla.org/en-US/docs/Web/API/Element.matches which > reflects the state of things much better. Note that the name > matchesSelector has been gone from the standard for a long time now. > > > > So.. Ok to keep prefix working in all browsers, but not just add it? For > > the most part, isn't that just like an alias? > > Depends on the implementation details of the prefixed version. FWIW, > I'd expect Gecko to remove support for the prefixed version. Maybe > after some period of emitting warnings. We've done that successfully > for a whole bunch of things. > > > -- > http://annevankesteren.nl/ I think there may be confusion because of where in the thread i responded - it was unclear who i was responding to (multi). I pointed to web platform link because it is an example of a respected source: a) showing "how to write it for forward compat" b) assuming that, based on old/popular decision it would be called matches. I didnt use the moz ref because i think it is misleading in that: a) unlike a *lot* of other moz refs, it doesn't show anything regarding using it with other prefixes/unprefixing b) the state of that doc now still wouldn't be what someone referenced in a project they wrote 6 months or a year ago. My entire point is that it seems, unfortunately, in this very specific case, kind of reasonable that: A) Element.prototype.matches() has to mean what .mozMatchedSelector() means today. It shouldn't be reconsidered, repurposed or worrisome. B) Enough stuff assumes Element.prototype.matchesSelector() to cause me worry that it will prevent unprefixing. C) We could bikeshed details all day long, but why not just add both where one is an alias for the other. Then, what Anne said about dropping prefix over time becomes less troubling as the number of people who did neither and don't rev becomes vanishingly small (still, if it is easy why drop at all). Very succinctly, i am suggesting: .matchesSector be unprefixed, .matches is an alias and docs just say "see matchesSelector, its an alias." And no one breaks. And we avoid this in the future by following better practices.
Re: Making selectors first-class citizens
On Sat, Sep 14, 2013 at 4:26 AM, Brian Kardell wrote: > I am not really sure why you feel this way - this piece of the draft is > tremendously stable, and interoperable as anything else. The decision to > make it matches was old and popular. It's not just random joe schmoe doing > this, it's illustrated and recommended by respected sources... For example > http://docs.webplatform.org/wiki/dom/methods/matchesSelector 1) I don't think that's a respected source just yet. 2) When I search for matchesSelector on Google I get https://developer.mozilla.org/en-US/docs/Web/API/Element.matches which reflects the state of things much better. Note that the name matchesSelector has been gone from the standard for a long time now. > So.. Ok to keep prefix working in all browsers, but not just add it? For > the most part, isn't that just like an alias? Depends on the implementation details of the prefixed version. FWIW, I'd expect Gecko to remove support for the prefixed version. Maybe after some period of emitting warnings. We've done that successfully for a whole bunch of things. -- http://annevankesteren.nl/
Re: Making selectors first-class citizens
On Sep 13, 2013 4:38 PM, "Ryosuke Niwa" wrote: > > > On Sep 11, 2013, at 11:54 AM, Francois Remy wrote: > >> For the record, I'm equally concerned about renaming `matchesSelector` into `matches`. >> >> A lot of code now rely on a prefixed or unprefixed version of `matchesSelector` as this has shipped in an interoperable fashion in all browsers now. > > > Which browser ships matchesSelector unprefixed? > Neither Chrome, Firefox, nor Safari ship matchesSelector unprefixed. > > > On Sep 13, 2013, at 1:12 PM, Francois Remy wrote: > A lot of code now rely on a prefixed or unprefixed version of `matchesSelector` as this has shipped in an interoperable fashion in all browsers now. >>> >>> >>> Unprefixed? >> >> >> Yeah. Future-proofing of existing code, mostly: >> >> >> https://github.com/search?q=matchesSelector+msMatchesSelector&type=Code&ref >> =searchresults > > > That’s just broken code. One cannot speculatively rely on unprefixed DOM functions until they’re actually spec’ed and shiped. > I have no sympathy or patience to maintain the backward compatibility with the code that has never worked. > I am not really sure why you feel this way - this piece of the draft is tremendously stable, and interoperable as anything else. The decision to make it matches was old and popular. It's not just random joe schmoe doing this, it's illustrated and recommended by respected sources... For example http://docs.webplatform.org/wiki/dom/methods/matchesSelector Essentially, this reaches the level of de facto standard in my book. .all it really lacks is a vote. Prefixes bound to vendors which may or may not match final and may or may not disappear when final comes around or just whenever, in release channel is exactly why most people are against this sort of thing now. This predates that shift and regardless of whether we like it, stuff will break for people who were just following examples and going by the implementation/interop and standard perception of stability. Websites will stop working correctly - some will never get fixed - others will waste the time of hundreds or thousands of devs... This isn't something that was implemented by 1 or 2 browsers, was hotly contested or has only been around a few months: This is out there a long time and implemented a long time. > Furthermore, the existing code will continue to work with the prefixed versions since we’re not suggesting to drop the prefixed versions. > But, you could just as easily because it is prefixed and experimental. I guess i am just not understanding why we are ok to keep around the crappy named prefix ones but not alias the better name that is widely documented and definitely used just so we can bikeshed a bit more? If there is also something better, let's find a way to add without needing to mess with this. > - R. Niwa > So.. Ok to keep prefix working in all browsers, but not just add it? For the most part, isn't that just like an alias?
Re: Making selectors first-class citizens
>>A lot of code now rely on a prefixed or unprefixed version of >> `matchesSelector` as this has shipped in an interoperable fashion in all >> browsers now. > >Unprefixed? Yeah. Future-proofing of existing code, mostly: https://github.com/search?q=matchesSelector+msMatchesSelector&type=Code&ref =searchresults
Re: Making selectors first-class citizens
On Sep 11, 2013, at 11:54 AM, Francois Remy wrote: > For the record, I'm equally concerned about renaming `matchesSelector` into > `matches`. > > A lot of code now rely on a prefixed or unprefixed version of > `matchesSelector` as this has shipped in an interoperable fashion in all > browsers now. Which browser ships matchesSelector unprefixed? Neither Chrome, Firefox, nor Safari ship matchesSelector unprefixed. On Sep 13, 2013, at 1:12 PM, Francois Remy wrote: >>> A lot of code now rely on a prefixed or unprefixed version of >>> `matchesSelector` as this has shipped in an interoperable fashion in all >>> browsers now. >> >> Unprefixed? > > Yeah. Future-proofing of existing code, mostly: > > > https://github.com/search?q=matchesSelector+msMatchesSelector&type=Code&ref > =searchresults That’s just broken code. One cannot speculatively rely on unprefixed DOM functions until they’re actually spec’ed and shiped. I have no sympathy or patience to maintain the backward compatibility with the code that has never worked. Furthermore, the existing code will continue to work with the prefixed versions since we’re not suggesting to drop the prefixed versions. - R. Niwa
Re: Making selectors first-class citizens
On Wed, Sep 11, 2013 at 7:54 PM, Francois Remy wrote: > A lot of code now rely on a prefixed or unprefixed version of > `matchesSelector` as this has shipped in an interoperable fashion in all > browsers now. Unprefixed? -- http://annevankesteren.nl/
Re: Making selectors first-class citizens
For the record, I'm equally concerned about renaming `matchesSelector` into `matches`. A lot of code now rely on a prefixed or unprefixed version of `matchesSelector` as this has shipped in an interoperable fashion in all browsers now. I don't mind adding a new `matches` function that would take a Selector as an argument, or simply consider matchesSelector as a deprecated API and recommend to use Selector going forward, with a polyfill for older browsers, but I believe renaming `matchesSelector` at this time is a dangerous idea. The other option to keeping `matchesSelector` as is is to continue to ship the prefixed versions forever which seems a bad idea to me. -- standardize what's implemented, implement what's standardized.
Re: Making selectors first-class citizens
On Sep 12, 2013 2:16 AM, "Garrett Smith" wrote:
>
> FWD'ing to put my reply back on list (and to others)...
>
> On Sep 11, 2013 6:35 AM, Anne van Kesteren wrote:
>
> As far as I can tell Element.prototype.matches() is not deployed yet.
> Should we instead make selectors first-class citizens, just like
> regular expressions, and have
>
> var sel = new Selectors("i > love > selectors, so[much]")
> sel.test(node)
>
> # 2007 David Anderson proposed the idea.
>
> That seems like a much nicer approach.
>
> (It also means this can be neatly defined in the Selectors
> specification, rather than in DOM, which means less work for me. :-))
>
> # 2009 the API design remerged
> http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1445.html
>
> # 2010 Selectors explained in an article:
> http://www.fortybelow.ca/hosted/dhtmlkitchen/JavaScript-Query-Engines.html
> (search Query Matching Strategy).
> --
> Garrett
> Twitter: @xkit
> personx.tumblr.com
>
I may be the only one, but... I am unsure what you are advocating here
Garrett.
Re: Making selectors first-class citizens
On Wed, Sep 11, 2013 at 9:49 PM, Robin Berjon wrote:
> On IRC Domenic pointed out that the primary apparent usage for this mirrors
> jQuery's .is(). Barring the caching case, it seems unlikely to be appealing
> to do (new Selectors("div")).matches(el) instead of el.matches("div").
Thanks for bringing that up here Robin. I added
Element.prototype.matches() to the specification:
http://dom.spec.whatwg.org/#dom-element-matches
See http://krijnhoetmer.nl/irc-logs/whatwg/20130912#l-365 for why it
does not have the refNodes argument anymore.
--
http://annevankesteren.nl/
Re: Making selectors first-class citizens
On 11/09/2013 17:22 , Boris Zbarsky wrote:
On 9/11/13 9:52 AM, Rick Waldron wrote:
A prime use case: a cache of selector objects that are useful when
matching event.target for event handler delegation patterns.
Note that UAs already do some internal caching of parsed selector
objects used with querySelector. Of course an explicit cache in the
script would likely be a tiny bit faster.
On IRC Domenic pointed out that the primary apparent usage for this
mirrors jQuery's .is(). Barring the caching case, it seems unlikely to
be appealing to do (new Selectors("div")).matches(el) instead of
el.matches("div").
One thing that /could perhaps/ be interesting with this though would be
as an extensibility point in which developers could bind parameters and
functions extending selectors. A selector object would be a logical
place to hang this off of. But that's a whole other kettle of fish.
--
Robin Berjon - http://berjon.com/ - @robinberjon
Re: Making selectors first-class citizens
On 11/09/13 15:50, Brian Kardell wrote: Yes, to be clear, that is what i meant. If it is in a draft and widely/compatibly implemented and deployed in released browsers not behind a flag - people are using it. If people are using a prefixed — i.e. proprietary — API there is no requirement that a standard is developed and shipped for that API. It's then up to the individual vendor to decide whether to drop their proprietary feature or not.
Re: Making selectors first-class citizens
On Sep 11, 2013 10:04 AM, "Robin Berjon" wrote:
>
> On 11/09/2013 15:56 , Anne van Kesteren wrote:
>>
>> On Wed, Sep 11, 2013 at 2:52 PM, Brian Kardell
wrote:
>>>
>>> I like the idea, but matches has been in release builds for a long time,
>>> right? Hitch uses it.
>>
>>
>> .w("matches" in document.body)
>> http://software.hixie.ch/utilities/js/live-dom-viewer/
>>
>> false in both Firefox and Chrome.
>
>
> See http://caniuse.com/#search=matches. You do get mozMatchesSelector
(and variants) in there.
>
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
Yes, to be clear, that is what i meant. If it is in a draft and
widely/compatibly implemented and deployed in released browsers not behind
a flag - people are using it. That's part of why we switched the general
philosophy right? No doubt one can be a shorthand for the better approach
though...right?
Re: Making selectors first-class citizens
On Sep 11, 2013 12:29 PM, "Boris Zbarsky" wrote: > > On 9/11/13 12:26 PM, Brian Kardell wrote: >> >> If something with the same name but different >> signature or functionality goes out unprefixed, things will break. > > > Why is this, exactly? Is code assuming that "mozFoo", "webkitFoo" and "foo" are interchangeable? Because they sure aren't, in general. > > In any case, there is no "mozMatches" or "webkitMatches", so "matches" should be ok. As things mature to the manner/degree i described, yes. But, this isn't surprising, right? When things reach this level, we feel pretty comfortable calling them polyfills which do exactly what you describe: We assume prefixed and unprefixed are equivalent. We also feel comfortable listing them on sites like caniuse.com and even working group members have products that effectively just unprefix. It's the same logic used by Robert O'Callahan regarding unprefixing CSS selectors[1] and we ended up doing a lot of that - and even prior to that there was talk of unprefixing .matchesSelector as .matches right here on public web-apps[2]. When things reach this point, we really have to consider what is out there and how widely it has been promoted for how long. I think it is too late for matchesSelector for sure, and I'd be lying if I said I wasn't worried about .matches(). I for one am very glad we are taking approaches that help us not be in this boat - but the idea that something can be called as a constructor or not isn't new either - can we make it backwards compat and get the best of both worlds? Given the similarities in what they do, it doesn't seem to me like implementation is a problem. In the very least, I feel like we need to retain .matchesSelector for some time. [1] http://lists.w3.org/Archives/Public/www-style/2011Nov/0271.html [2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1146.html > > -Boris > >
Re: Making selectors first-class citizens
On 9/11/13 12:26 PM, Brian Kardell wrote: If something with the same name but different signature or functionality goes out unprefixed, things will break. Why is this, exactly? Is code assuming that "mozFoo", "webkitFoo" and "foo" are interchangeable? Because they sure aren't, in general. In any case, there is no "mozMatches" or "webkitMatches", so "matches" should be ok. -Boris
Re: Making selectors first-class citizens
On Wed, Sep 11, 2013 at 12:26 PM, Brian Kardell wrote: > > On Sep 11, 2013 11:11 AM, "James Graham" wrote: > > > > On 11/09/13 15:50, Brian Kardell wrote: > > > >> Yes, to be clear, that is what i meant. If it is in a draft and > >> widely/compatibly implemented and deployed in released browsers not > >> behind a flag - people are using it. > > > > > > If people are using a prefixed — i.e. proprietary — API there is no > requirement that a standard is developed and shipped for that API. It's > then up to the individual vendor to decide whether to drop their > proprietary feature or not. > > > > > > Please note carefully what i said. I don't think I am advocating anything > that hasn't been discussed a million times. In theory what you say was the > original intent. In practice, that's not how things went. Browsers have > changed what used to be standard practice to help avoid this in the > future. We are making cross-browser prollyfills outside browser > implementations to avoid this in the future. What is done is done though. > The reality is that real and not insignificant production code uses > prefixed things that meet the criteria I stated. If removed, those will > break. If something with the same name but different signature or > functionality goes out unprefixed, things will break. > Mozillians, just for example: https://github.com/x-tag/x-tag/blob/master/dist/x-tag-components.js#L2161 -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Making selectors first-class citizens
On Sep 11, 2013 11:11 AM, "James Graham" wrote: > > On 11/09/13 15:50, Brian Kardell wrote: > >> Yes, to be clear, that is what i meant. If it is in a draft and >> widely/compatibly implemented and deployed in released browsers not >> behind a flag - people are using it. > > > If people are using a prefixed — i.e. proprietary — API there is no requirement that a standard is developed and shipped for that API. It's then up to the individual vendor to decide whether to drop their proprietary feature or not. > > Please note carefully what i said. I don't think I am advocating anything that hasn't been discussed a million times. In theory what you say was the original intent. In practice, that's not how things went. Browsers have changed what used to be standard practice to help avoid this in the future. We are making cross-browser prollyfills outside browser implementations to avoid this in the future. What is done is done though. The reality is that real and not insignificant production code uses prefixed things that meet the criteria I stated. If removed, those will break. If something with the same name but different signature or functionality goes out unprefixed, things will break.
Re: Making selectors first-class citizens
On 9/11/13 9:52 AM, Rick Waldron wrote: A prime use case: a cache of selector objects that are useful when matching event.target for event handler delegation patterns. Note that UAs already do some internal caching of parsed selector objects used with querySelector. Of course an explicit cache in the script would likely be a tiny bit faster. -Boris
Re: Making selectors first-class citizens
On Wed, Sep 11, 2013 at 2:52 PM, Rick Waldron wrote: > A prime use case: a cache of selector objects that are useful when matching > event.target for event handler delegation patterns. Can you describe the > Selector instance object a little more? Thanks! It would be called Selectors, not Selector, as it represents a group of selectors (as always with selectors). It would be opaque as to allow for optimizations to the data model over time. And it would have a test method that takes an element and returns either true or false as to whether it's a match for that node given node's root (defined in DOM). We could add more methods in the future if the above first step works out. E.g. selectors.match(tree) -> Elements object and such. -- http://annevankesteren.nl/
Re: Making selectors first-class citizens
On 11/09/2013 15:56 , Anne van Kesteren wrote:
On Wed, Sep 11, 2013 at 2:52 PM, Brian Kardell wrote:
I like the idea, but matches has been in release builds for a long time,
right? Hitch uses it.
.w("matches" in document.body)
http://software.hixie.ch/utilities/js/live-dom-viewer/
false in both Firefox and Chrome.
See http://caniuse.com/#search=matches. You do get mozMatchesSelector
(and variants) in there.
--
Robin Berjon - http://berjon.com/ - @robinberjon
Re: Making selectors first-class citizens
On Wed, Sep 11, 2013 at 2:52 PM, Brian Kardell wrote:
> I like the idea, but matches has been in release builds for a long time,
> right? Hitch uses it.
.w("matches" in document.body)
http://software.hixie.ch/utilities/js/live-dom-viewer/
false in both Firefox and Chrome.
--
http://annevankesteren.nl/
Re: Making selectors first-class citizens
On Wed, Sep 11, 2013 at 9:33 AM, Anne van Kesteren wrote:
> As far as I can tell Element.prototype.matches() is not deployed yet.
> Should we instead make selectors first-class citizens, just like
> regular expressions, and have this:
>
> var sel = new Selectors("i > love > selectors, so[much]")
> sel.test(node)
>
A prime use case: a cache of selector objects that are useful when matching
event.target for event handler delegation patterns. Can you describe the
Selector instance object a little more? Thanks!
Rick
Re: Making selectors first-class citizens
On Sep 11, 2013 9:34 AM, "Anne van Kesteren" wrote:
>
> As far as I can tell Element.prototype.matches() is not deployed yet.
> Should we instead make selectors first-class citizens, just like
> regular expressions, and have this:
>
> var sel = new Selectors("i > love > selectors, so[much]")
> sel.test(node)
>
> That seems like a much nicer approach.
>
> (It also means this can be neatly defined in the Selectors
> specification, rather than in DOM, which means less work for me. :-))
>
>
> --
> http://annevankesteren.nl/
>
I like the idea, but matches has been in release builds for a long time,
right? Hitch uses it.
