#14600 closed bug (notabug)
trigger('remove') calls remove() method on DOM element
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | undecided | Milestone: | None |
Component: | unfiled | Version: | 1.10.2 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
calling trigger with an event "remove" or any name spaced remove.foo, remove.bar will remove that DOM element.
This occurs: https://github.com/jquery/jquery/blob/master/src/event.js#L338
Example: http://codepen.io/anon/pen/fezvF
Change History (4)
comment:1 Changed 9 years ago by
Resolution: | → notabug |
---|---|
Status: | new → closed |
comment:2 Changed 9 years ago by
scott.gonzalez
Would you recommend always using event.preventDefault() when triggering custom events(NOT 'blur', 'change', 'click', 'focus' and so on) then?
Even though this has been labeled 'notabug', I doubt the original intent was to fire non-event related functions. I'd think that its use was to call 'blur', 'change', 'click', 'focus' and so on. 'remove' was not a function that a DOM element had available at the time this functionality was created. I could name an event type, 'insertBefore' and then I'd get an error in the console because I tried to call the DOM method with an incorrect number of parameters. While this may not technically be a bug, I'd say it's not following the intent of the event model.
Thoughts?
comment:3 follow-up: 4 Changed 9 years ago by
Would you recommend always using event.preventDefault() when triggering custom events
No. I would recommend not using names that have easy collisions. Put a colon in your custom event name.
comment:4 Changed 9 years ago by
Replying to scott.gonzalez:
Thanks Scott. This is what I was looking for; using a colon for custom events makes sense. It prevents me or anyone else on our team from needing to know the future of DOM functionality. 'remove' was once a fine name to use but is no longer.
Thanks
As documented on http://api.jquery.com/trigger/: