Re: Making selectors first-class citizens

On Sep 13, 2013 4:38 PM, "Ryosuke Niwa" <rniwa@apple.com> wrote:
>
>
> On Sep 11, 2013, at 11:54 AM, Francois Remy <remy@adobe.com> 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 <remy@adobe.com> 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?