Re: Making selectors first-class citizens

On Sep 11, 2013 12:29 PM, "Boris Zbarsky" <bzbarsky@mit.edu> 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
>
>