Opened 10 years ago
Closed 10 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:1 Changed 10 years ago by
comment:5 Changed 10 years ago by
Component: | unfiled → selector |
---|---|
Priority: | undecided → low |
Status: | new → open |
comment:7 Changed 10 years ago by
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 follow-up: 9 Changed 10 years ago by
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 follow-up: 10 Changed 10 years ago by
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 Changed 10 years ago by
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?
comment:11 Changed 10 years ago by
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 10 years ago by
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 10 years ago by
I see timmywill has removed docElem.matchesSelector
from Sizzle as I suggested.
This ticket can now be closed, obviously.
comment:14 Changed 10 years ago by
Resolution: | → notabug |
---|---|
Status: | open → closed |
The correct link is:
http://www.w3.org/TR/selectors-api2/#interface-definitions