On Mon, Sep 16, 2013 at 1:05 PM, Brian Kardell <bkard...@gmail.com> 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