-
-
Save getify/579849 to your computer and use it in GitHub Desktop.
$("#foo").click(function(e){ | |
if (e.clientX) { | |
// native mouse click | |
} | |
else { | |
// triggered mouse click | |
} | |
}); |
I've come across a seemingly valid use case when creating bookmarklets and extensions interacting with existing, scope-protected widgets using mouse/keyboard input. Not something you'd do everyday, but it would probably be impossible without the ability to simulate native events, no?
@krawaller -- i don't deny that might be a valid (but very niche) case... but it fits closely with "automation".
what i'm opposed to is that people use this technique as a general coding pattern... like: "i have a button i want users to click on, and also i want to have another action that can pretend to click the button (like enter
), so what i'm gonna do is code behavior against click
only and then hide the detail that something else can also fire that click
."
in my opinion, this is an anti-pattern, because you are creating a connection between two pieces of code that is much harder to decipher and debug. it's kinda like putting event handler code inside inline attributes, mixing markup and code. does it work? yeah. but is it a good idea? hell no.
instead, you could/should have bound two separate events to the same handler. that would accomplish the same goal and be a lot cleaner and more understandable/maintainable code.
Firing events can be used in cross-browser event delegation solutions to normalize inconsistent event bubbling.
Prototype uses DOM events, and their firing, to support custom event's that piggyback off of real events.
This has some advantages like if 1 handler fails the others will continue to execute.
instead, you could/should have bound two separate events to the same handler. that would accomplish the same goal and be a lot cleaner and more understandable/maintainable code.
You will end up having issues syncing the two events when one is told to stop bubbling and the other is unaware.
And what do you think would be used to fire
these secondary custom events? That would be the same API you called evil :D
@jdalton - triggering events is definitely not evil. in my opinion, triggering a native event is bad. triggering a native event and pretending to be that native event with bogus information like fake mousex/mousey values is evil.
@getify Indeed - as a general coding pattern, it's really bad practice. However, the solution is not to remove the support à la
i would consider that kind of code (and the ability to do it in JavaScript and jQuery, etc) wrong and evil
We shouldn't remove democracy just because it lets us do evil, right? ;)
@krawaller -- i mean, i understand your point. not necessarily saying it should be removed, but it should be avoided under almost all cases, just like what crockford says about the "good parts" and "bad parts" -- i definitely consider that a "bad part".
btw, there are some things that are so evil they should be removed... like "document.write"... my new banner: "document.write() must die". :)
someone please explain to me, other than test frameworks (automation), why is it a good thing to simulate a native event including simulating inaccurate mouse coordinates?