#13530 closed bug (notabug)
Inconsistent results with .has since 1.8.3. Should .has selector match element itself or its parents?
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | low | Milestone: | None |
Component: | traversing | Version: | 1.9.1 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
The behavior of .has seems to have changed somewhere between 1.7.2 and 1.8.3. I'm not sure if this is a bug or a deliberate change, but thought I'd post it here just in case.
For something like
$elem.has('selector')
In older versions, if the selector included something about $elem as a parent of things to match, it would still match and the element would return. In newer code, the descendants don't match anymore.
You can observe the inconsistency at this fiddle: http://jsfiddle.net/6BMP4/1/ (Go to the left to change jQuery versions and hit run again to see what I'm talking about)
I've looked at the change logs between those two releases and 1.8 is the only one that seems to address .has and it doesn't note this change specifically.
I'm not sure what the "right" answer is in this regard, but I figure I'd bring it up here.
Change History (4)
comment:1 follow-up: 2 Changed 10 years ago by
Component: | unfiled → traversing |
---|---|
Priority: | undecided → low |
Resolution: | → notabug |
Status: | new → closed |
comment:2 Changed 10 years ago by
That sounds fine.
My one remaining comment on the issue is that the docs for .has could be a little more explicit about what can be matched against. It's not necessarily the most intuitive thing that the same selector, when passed to the jQuery constructor, would match a particular element's children but not when passed to .has
on the same element. Perhaps the note could mention how the behavior did change in v1.8.0.
It's not that big of a deal, but such a note might save someone a little trouble when they're updating a big codebase to a newer version of jQuery.
Replying to gibson042:
This was a side effect of fixing #11543, fixed in v1.8.0. The current behavior is more consistent with our explicit deviations from
querySelectorAll
, especially considering that we never looked outside of the container.In fact, it would also have been fixed by Sizzle getting a consistent and proper
contains
sometime last year, so this strikes me as proper behavior.I'm going to close this, but would consider reopening if someone makes a sufficiently persuasive argument.
comment:3 Changed 10 years ago by
Sure; thanks. Can you open an issue or pull request at https://github.com/jquery/api.jquery.com?
comment:4 Changed 10 years ago by
I probably wont get to it until the weekend, but I can do that.
Thanks.
This was a side effect of fixing #11543, fixed in v1.8.0. The current behavior is more consistent with our explicit deviations from
querySelectorAll
, especially considering that we never looked outside of the container.In fact, it would also have been fixed by Sizzle getting a consistent and proper
contains
sometime last year, so this strikes me as proper behavior.I'm going to close this, but would consider reopening if someone makes a sufficiently persuasive argument.