Posted in Developing, JavaScript, Technology Please give him feedback and comments so he can find any eventual flaws. Therefore, I encourage you to take a look it, test it and read the explanation to his approach. I’m going to be honest here and admit that I, due to lack of time, haven’t tested Aaron’s solution extensively, but I thought it was an interesting angle to the solution, and from what I’ve seen so far, it looks very clever too. However, it unfortunately lacks a way to specify capturing phase. You can specify in what order event handlers should run.It easily allows for making a script to see what event handlers are registered to an element.It allows for cancellation of default event behavior.It supports, naturally, multiple event handlers.The function is interesting for a number of reasons: element.onclick = functionToCall, and does not rely on the addEventListener or the attachEvent one. His addEvent is based on direct assignment, i.e. ![]() Recently I was approached by a student of the name Aaron Moore at the Gonzaga University, politely asking me to take a look at his version of event handling. After that, there were some voices raised about the winner and his solution, and JavaScript hero Dean Edwards (amongst many others) released his version of addEvent. A competitionĮventually all this led to a addEvent() recoding contest where a lot of people contributed and a winner was announced. This is most likely due to IE only having one global event object, as opposed to the standard model where events are local and passed with the function call (for a more detailed write-up, read Peter-Paul Koch’s Advanced event registration models article, and for a more real-life scenario, read his addEvent() considered harmful both good reads). Var strElementId = this.getAttribute("id") This code below will fail because of IE's incorrect reference for the "this" keyword Note that the addEvent function referred to below is a custom function, not built-inĪddEvent(oElement, "click", handleClick) Var oElement = document.getElementById("my-div") Unfortunately, in IE, it refers to the window object instead when using the attachEvent method. Normally, using the this keyword in a function regarding to an event should refer to the element the event occurred on. The problem with Scott’s method, though, is that for IE you can’t use the this keyword in the function that receives the event. The solution for this was presented as far back as in 2001 by Scott Andrew LePera in his Crossbrowser DOM Scripting: Event Handlers, which uses the standard addEventListener method for web browsers who support it, and has a fallback for IE by using its proprietary attachEvent method. Second, normally you might want to apply several event handlers to the same event on an element without knowing (or needing to know) if there has already been assigned any, and also without overwriting any potential existing event handlers. There is a W3C standardized event handling model that Microsoft doesn’t abide to, but they instead have created their own model (this is one of times I almost resort to actually supporting Dvorak’s The Great Microsoft Blunder, but that’s really a rant for another day…).įirst, you never want to apply event handlers inline. ![]() The gist of the problems is, surprise, Internet Explorer (yeah, I know, it’s a shocker…). What’s the problem with event handling in JavaScript? My idea here is to give you a basic background and to also tell you about a new and interesting solution. When I wrote my post AJAX, JavaScript and accessibility some commenters were asking for a follow-up post explaining event handling in JavaScript. Event handling in JavaScript – an alternative addEvent solution Published on Wednesday, August 30, 2006Įvent handling in JavaScript has been an issue for many web developers, and countless of people have made their stab of solving it.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |