[thelist] javascript default event handlers, default events. [TIP]
Sam Foster
sam at sam-i-am.com
Thu Sep 8 23:06:50 CDT 2005
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.
>
>
More information about the thelist
mailing list