Re: Making selectors first-class citizens

On Sep 14, 2013 6:07 AM, "Anne van Kesteren" <annevk@annevk.nl> wrote:
>
> On Sat, Sep 14, 2013 at 4:26 AM, Brian Kardell <bkardell@gmail.com> wrote:
> > 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
>
> 1) I don't think that's a respected source just yet. 2) When I search
> for matchesSelector on Google I get
> https://developer.mozilla.org/en-US/docs/Web/API/Element.matches which
> reflects the state of things much better. Note that the name
> matchesSelector has been gone from the standard for a long time now.
>
>
> > 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?
>
> Depends on the implementation details of the prefixed version. FWIW,
> I'd expect Gecko to remove support for the prefixed version. Maybe
> after some period of emitting warnings. We've done that successfully
> for a whole bunch of things.
>
>
> --
> http://annevankesteren.nl/

I think there may be confusion because of where in the thread i responded -
it was unclear who i was responding to (multi).  I pointed to web platform
link because it is an example of a respected source: a) showing "how to
write it for forward compat" b) assuming that, based on old/popular
decision it would be called matches.

I didnt use the moz ref because i think it is misleading in that: a) unlike
a *lot* of other moz refs, it doesn't show anything regarding using it with
other prefixes/unprefixing b) the state of that doc now still wouldn't be
what someone referenced in a project they wrote 6 months or a year ago.

My entire point is that it seems, unfortunately, in this very specific
case, kind of reasonable that:
A) Element.prototype.matches() has to mean what .mozMatchedSelector() means
today.  It shouldn't be reconsidered, repurposed or worrisome.
B) Enough stuff assumes Element.prototype.matchesSelector() to cause me
worry that it will prevent unprefixing.
C) We could bikeshed details all day long, but why not just add both where
one is an alias for the other.  Then, what Anne said about dropping prefix
over time becomes less troubling as the number of people who did neither
and don't rev becomes vanishingly small (still, if it is easy why drop at
all).

Very succinctly, i am suggesting:
.matchesSector be unprefixed, .matches is an alias and docs just say "see
matchesSelector, its an alias." And no one breaks.  And we avoid this in
the future by following better practices.