As documented on http://api.jquery.com/trigger/:

Note: For both plain objects and DOM objects other than window, if a triggered event name matches the name of a property on the object, jQuery will attempt to invoke the property as a method if no event handler calls event.preventDefault(). If this behavior is not desired, use .triggerHandler() instead.

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?

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.

Replying to [comment:3 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