Bug Tracker

Opened 7 years ago

Closed 7 years ago

#13629 closed bug (notabug)

Rename matchesSelector to matches

Reported by: m_gol Owned by:
Priority: low Milestone: None
Component: selector Version: 2.0b2
Keywords: Cc:
Blocked by: Blocking:

Description

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.

Change History (14)

comment:3 Changed 7 years ago by m_gol

Sizzle needs more similar changes btw.

comment:5 in reply to:  3 Changed 7 years ago by timmywil

Component: unfiledselector
Priority: undecidedlow
Status: newopen

Replying to m_gol:

Sizzle needs more similar changes btw.

A Sizzle issue would be perfect. :)

comment:7 Changed 7 years ago by 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.

comment:8 Changed 7 years ago by 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.

comment:9 in reply to:  8 ; Changed 7 years ago by 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.

comment:10 in reply to:  9 Changed 7 years ago by 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?

Last edited 7 years ago by m_gol (previous) (diff)

comment:11 Changed 7 years ago by 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.

comment:12 Changed 7 years ago by 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?

comment:13 Changed 7 years ago by m_gol

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

This ticket can now be closed, obviously.

Last edited 7 years ago by m_gol (previous) (diff)

comment:14 Changed 7 years ago by dmethvin

Resolution: notabug
Status: openclosed
Note: See TracTickets for help on using tickets.