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: should mutation observers be able to observe work done by the html parser
Yup. Not sure where this is in W3C DOM, but 12.2.5.1 Creating and inserting nodes (http://www.whatwg.org/specs/web-apps/current-work/) ... DOM mutation events must not fire for changes caused by the UA parsing the document. This includes the parsing of any content inserted using document.write() and document.writeln() calls. [DOMEVENTS] However, mutation observers do fire, as required by the DOM specification. ... On Mon, Sep 16, 2013 at 8:13 AM, Brian Kardell wrote: > was therw ever agreement on this old topic? > http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0618.htmlwhether > by de facto implementation or spec agreements? I am not seeing > anything in the draft but maybe i am missing it... >
Re: should mutation observers be able to observe work done by the html parser
was therw ever agreement on this old topic? http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0618.htmlwhether by de facto implementation or spec agreements? I am not seeing anything in the draft but maybe i am missing it...
