Rename matchesSelector to matches

[m_gol]

According to the current version of the spec:
​http://www.w3.org/TR/selectors-api2/#interface-definitions[[BR]] The correct name is matches, not matchesSelector.

[m_gol]

The correct link is:
​http://www.w3.org/TR/selectors-api2/#interface-definitions

[m_gol]

Pull request:
​https://github.com/jquery/jquery/pull/1206

[m_gol]

Sizzle needs more similar changes btw.

[m_gol]

Relevant: ​http://caniuse.com/matchesselector

[Timmy Willison]

Replying to m_gol:

Sizzle needs more similar changes btw.

A Sizzle issue would be perfect. :)

[m_gol]

Here you are: ​https://github.com/jquery/sizzle/issues/198

[scottgonzalez]

Shouldn't we wait for at least one browser to implement this or for the spec to actually be stable? So far you've pointed at 2 sources: 1) The new spec, which specifically says that it is not stable; 2) caniuse which says that not a single browser supports the new name.

[m_gol]

I'll repeat my comment from pull request: consequently, you should also remove docElem.matchesSelector (and only leave prefixed versions) since it was taken from an unfinished specification not implemented anywhere as well.

If that's what you prefer, I can update my pull requests. I just can think of no reason to keep in the code a method name implemented nowhere and taken from an unstable and out-of-date working draft so, IMHO, it should be changed anyway, one way or the other.

[scottgonzalez]

Replying to m_gol:

I'll repeat my comment from pull request: consequently, you should also remove docElem.matchesSelector (and only leave prefixed versions) since it was taken from an unfinished specification not implemented anywhere as well.

Except that prefixed versions WERE implemented. We should always wait for at least one implementation before writing code to support a proposed feature.

PLEASE PLEASE PLEASE DO NOT lock browser vendors into an API based on an unstable spec and a previous prefixed implementation. We're killing the standards process if we do.

[m_gol]

I'll repeat my comment from pull request: consequently, you should also remove docElem.matchesSelector (and only leave prefixed versions) since it was taken from an unfinished specification not implemented anywhere as well.

Except that prefixed versions WERE implemented.

Exactly. Prefixed versions were implemented, e.g. mozMatchesSelector & webkitMatchesSelector were implemented; matchesSelector hasn't been implemented anywhere. What I'm saying is that I understand your concerns but it means that the code:

matches = docElem.matchesSelector ||
		docElem.mozMatchesSelector ||
		docElem.webkitMatchesSelector ||
		docElem.oMatchesSelector ||
		docElem.msMatchesSelector

should be changed to:

matches = docElem.mozMatchesSelector ||
		docElem.webkitMatchesSelector ||
		docElem.oMatchesSelector ||
		docElem.msMatchesSelector

i.e. the docElem.matchesSelector part should be completely removed.

Do you want me to make such a change?

[scottgonzalez]

It seems a bit premature to assume no browser vendor will implement an unprefixed matchesSelector. However, I don't have a strong opinion on whether it stays or goes.

[m_gol]

Does it happen for browser vendors to implement an unprefixed version of an experimental feature based on an out-of-date spec working draft?

[m_gol]

I see timmywill has removed docElem.matchesSelector from Sizzle as I suggested.

This ticket can now be closed, obviously.