Re: Making selectors first-class citizens

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

Received on Monday, 16 September 2013 20:29:55 UTC