Disable TR onclick event
in [JavaScript]
|
Prev: Ping
Next: onmouseleave Firefox equivalent
From: Richard Cornford on 15 Jun 2006 15:50 petermichaux(a)gmail.com wrote: <snip> > I should point out that there is one bonus of using a flag > to stop the tr onclick event handler from firing. If you have > other listeners higher up the DOM than tr that you also want to > have fire when either tr or td are clicked, then the flag will > just bypass one level in the bubble up when td is clicked. If > you stop the event altogether you can't do this, as far as I > know. If you stop an event propagating then you stop it propagating, but that does no necessitate the use of a global variable. The handler on the TR could make an informed decision not to act when it received the event, letting it carry on bubbling if necessary. It could, for example, observe the that target of the event was either a TD, or contained within an TD, that had a function assigned to the pertinent event handler property, and so elect not to act. Richard.
From: Richard Cornford on 15 Jun 2006 15:50 petermichaux(a)gmail.com wrote: > Richard Cornford wrote: >> petermichaux(a)gmail.com wrote: >> <snip> >> > It would be nice if there is some thing clean like a >> > return false that would stop the tr handler from firing. >> > I don't know if there is. >> <snip> >> >> Understanding how events work in web browsers is fairly >> fundamental to programming a browser as a GUI. It is >> difficult to see how anyone learning to script web browsers >> could avoid learning this aspect of the task within a few >> months of starting to make the effort (with the exceptions >> of being VK or placing an unreasonable reliance on the >> internal details of a library/framework, the internals of >> which they did not understand). >> >> I hope you will remember the outcome of this thread next >> time you are considering directing people to particular >> sources of information, or recommending particular >> libraries/frameworks. If you really were qualified to >> judge you would not be expected to be deficient in the >> fundamentals of browser scripting. > > Hi Richard, > > I only use DOM Level 2 event handling That would be your choice if you can get away with it, but commercial script authors cannot afford to disregard the IE event handling mechanisms. > and have never looked at how stopping event propogation > works with the attribute event handlers. Which just happens to be identical to the DOM events method on DOM standard browsers. > I said it would be nice if there was a way and there is. > That's nice. I learned something by joining in the discussion. You learnt something by joining the discussion _here_. > I'm pleased to be > using DOM level 2 event handling daily and using it well. But at some point you may find an advantage in becoming qualified to do commercial browser script development, for which you must learn how IE does it. > People here have been very unfriendly to those asking about > Prototype.js. Some people have. I have been attempting to get them to present their questions in a form that can be answered (i.e. in the form recommended in the expansion on the FAQ provided in the linked notes). To date nobody has managed to do that, but if anyone ever does we may manage to get past the generalities of Prototype.js and down to the actual code. > They may not have a choice in using it or not. Maybe, but even if they had to use it that doesn't mean they have to use it badly, and my impression of the Prototype.js questions that have been answered here is that the answered presented have all been seriously sub-optimal. But that will remain just an impression while the questions asked are insufficient to receive a fully informed answer. > Recently I've never said much more than "you might have better > luck asking on the rails spinoffs list". Yes, you are proposing they ask browser scripting questions in the place where you have been falling to learn the basics of browser event handling. Greater benefit would follow for all if you encouraged people to ask their questions in a form that they could/would be answered here. Richard.
From: Richard Cornford on 15 Jun 2006 15:51 Tony wrote: > Richard Cornford wrote: <snip> >> Understanding how events work in web browsers is fairly >> fundamental to programming a browser as a GUI. ... <smnip> > Given that, would you care to offer some sources of > information regarding this sort of scripting? I expect so, Richard.
From: Tony on 15 Jun 2006 17:18 Richard Cornford wrote: > Tony wrote: > >>Richard Cornford wrote: > > <snip> > >>>Understanding how events work in web browsers is fairly >>>fundamental to programming a browser as a GUI. ... > > <smnip> > >>Given that, would you care to offer some sources of >>information regarding this sort of scripting? > > I expect so, > > Richard. Now that's not playing nice... Since you insist: Other than the already provided link to Quirksmode, please suggest some sources of information regarding advanced event handling and scripting. -- "The most convoluted explanation that fits all the available and made-up facts is the most likely to be believed by conspiracy theorists"
From: petermichaux on 17 Jun 2006 21:56
Richard Cornford wrote: > petermichaux(a)gmail.com wrote: > <snip> > > I should point out that there is one bonus of using a flag > > to stop the tr onclick event handler from firing. If you have > > other listeners higher up the DOM than tr that you also want to > > have fire when either tr or td are clicked, then the flag will > > just bypass one level in the bubble up when td is clicked. If > > you stop the event altogether you can't do this, as far as I > > know. > > If you stop an event propagating then you stop it propagating, but that > does no necessitate the use of a global variable. The handler on the TR > could make an informed decision not to act when it received the event, > letting it carry on bubbling if necessary. It could, for example, > observe the that target of the event was either a TD, or contained > within an TD, that had a function assigned to the pertinent event > handler property, and so elect not to act. I'm working with a situation like this right now and can't find a clean way to make the type of decision you are suggesting. I have nested divs of various depth, some of which are listeners. It isn't as simple as looking to see if the target was within a TD. I suppose I could use a classname "listener" on each listening div. Then check if the event already bubbled through another "listener" before reaching the one currently handling the event. I don't really like the idea of using a classname for this. Seems like clutter. Is there a cross browser way to tag a particular event object as handled? It would be very clean if the event itself could carry information about which handlers have already seen the event. Thanks, Peter |