Re: Making selectors first-class citizens

On Mon, Sep 16, 2013 at 2:51 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

> On Sep 13, 2013, at 8:26 PM, Brian Kardell <bkardell@gmail.com> wrote:
>
>
> 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.
>
> 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