[thelist] javascript default event handlers, default events. [TIP]

[Sam Foster]

Wow, interesting discussion. I'm a card-carrying behavior 
layer/unobtrusive javascript proponent, but I think some great points 
were made in both directions.
Its true that troubleshooting javascript problems when implemented this 
way is made more difficult when there's no explicit event handler in the 
markup to provide a starting point or smoking gun. There can be 
something like strange magic from afar - doing a view-source might not 
be enlightening - you may be obliged to actually dig into the code and 
follow it through with a debugger... Especially if the concept is new to 
you.

The de-coupling of code/behavior from markup is more effective when you 
use something like document.getElementsBySelector. 
(http://simon.incutio.com/archive/2003/03/25/getElementsBySelector) .. 
this frees you from document.getElementById and needing a particular id 
to magically make everything work.

Like anything, there are good and bad ways to do it though. I'd 
recommend distinguishing between class attribute values that are used to 
to apply style, and those used to apply behavior. Its should be clear 
what is being triggered. I'm having some success with using a bvr- 
prefix to any classes that trigger behavior, and never using those 
classes in a stylesheet. Its just convention, but a good one IMO.

One more thing about inline function calls. I think the original 
example  - onsubmit="return validate(this)" - is indeed pretty well 
separated, and <form class="bvr-validate"> isnt any great improvement. 
Where you do see an improvement is where the behavior is more complex, 
where event handlers need to be attached to many elements. One classic 
example might be table row highlights - all I need is there is a trigger 
in the <table> element, or tbody and my script will go through and 
attach mouseover/out event handlers to each row programatically. Lots 
easier than writing and maintaining the event handlers as attributes on 
each row or cell. Or, frequently, if the markup is generated by some 
serverside process I dont own, modifying it might be entirely out of the 
question anyhow.
Devils advocate: if I'm trying to update the look and feel here, I may 
have to dig into the javascript to find out what css class is being 
appended to effect the row highlight. I'm a advocate of custom 
attributes for this kind of thing: <table class="bvr-highlightrows" 
rowhighlightclass="over"> or some such.

I think this technique is most useful when you are trying to patch in 
simple behavior like a row highlight, tooltip, or deferred content via 
ajax - where there aren't a lot of variables and behavior is easily 
defined. If you can say "I want this element to behave like one of 
these..." then its a good candidate.

All that said, if it aint broke dont fix it. I've adopted these 
techniques out of necessity - they solve a problem for me. If you don't 
have any problem that benefits from this technique then walk on by.

Some good links:
Javascript Triggers
http://www.alistapart.com/articles/scripttriggers/

Behavior - css selectors to select and apply js.
http://www.ripcord.co.nz/behaviour/

Dave Herman's behavior.js
http://www.ccs.neu.edu/home/dherman/javascript/behavior/

document.getElementsBySelector
http://simon.incutio.com/archive/2003/03/25/getElementsBySelector

also see Michael Schuerig's JavaScript for improvements to the above.
http://www.schuerig.de/michael/javascript/

Sam

>>If I change it to do the javascript: document.myForm.onsubmit =
>>myFormValidation, have I separated behaviour from markup?  Not as much - I
>>have an explicit markup reference to "myForm" to which I am programmatically
>>    
>>
>
>That is not a markup reference. It has nothing to do with markup.
>  
>