Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /share/CACHEDEV1_DATA/Web/www/libraries/UBBcode/text_parser.class.php on line 228

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /share/CACHEDEV1_DATA/Web/www/libraries/UBBcode/text_parser.class.php on line 228
Adding javascript triggers dynamically

Comments Blog About Development Research Sites

Adding javascript triggers dynamically

Nov 8, 2008
Or: why I once again hate firefox.

Let me start with the basic's. Adding a trigger to a DOM element dynamically is quite handy dandy since you seperate form from function. Or, to put it in more practical terms: when you have, for instance, a nice template component for date selection, you might want to include that at different locations. Trouble is, at each location it has to do something different javascript-wise.

Now you can of course go mess around with template variables and, in truth, that is actually slightly faster, but it is far from elegant. Rather you can just add the functionality dynamically by running a script that adds those triggers. Those familiar with ActionScript, the Flash' scripting language, should recognise the concept since it is very much alike the JavaScript way of doing things.

The practice: adding an onChange trigger
One of the first javascript functions I write for any given project is a fairly simple one:
Code (php) (nieuw venster):
1
2
3
4
5
6
7
8
/**
 *  Shortcut to document.getElementById(element) -
 *  instead you can now use $('element'); for the
 *  same result.
**/

function $ (elementId) {
  return
document.getElementById(elementId);
}


As the description says, this is a nice little shortcut for any situation where you might want to select an element by ID. Since I am fairly lazy, I'll only demonstrate this case:

Code (php) (nieuw venster):
1
2
3
4
5
6
$('day').onChange = alertDay;
$('day').onKeyUp  = alertDay;

function
alertDay () {
  alert($('day'));
}


Now anyone dabling in JavaScript ought to notice two peculiar things:

1. onChange and onKeyUp perform the same action
This is unfortunately due to FireFox. There are two ways of changing a select box: selecting a new value with your mouse, or selecting a new value with your keyboard. If you select a new value with your mouse, you change the value. If you select a new value with your keyboard, not so.

This is once again an example of why I hate FireFox. Sure, I fully believe anyone claiming that this behaviour is exactly according to the W3C or whatever other standards they might find, but for crying out loud, YOU CHANGE THE VALUE! Am I the only one thinking that ought to fire an onChange event?

Well, obviously not, because Internet Explorer does fire it when you change a selectbox value with your keyboard. So, if you hate FireFox and don't have a boss or customer to worry about, forget about the onKeyUp event.

2. The action is a function-name without the ()'s
It might, once again, be me, but I would expect an action to be either a function-call or a string with a function-name. Obviously, it is neither; this does however make javascript and actionscript more alike.

I have not implemented this, but in FireFox the alertDay function actually takes a reference to the event object as parameter, which is the same as window.event in IE. Event objects in turn have nifty properties such as event.clientX that store the location of where a user's mouse was during the event.

Wrapping it up
A page you seem to get linked to everywhere else so I'll link it here as well: href=http://www.alistapart.com/articles/scripttriggers/>a list apart has a good article on adding triggers to non-ID based DOM's. Most is fairly straight forward, but a good read nonetheless.

As a cute l'll example of my own: if you include this javascript file on a page with a body element, it'll give you a bug you can chase around your screen and even kill.

FragFrog out!

Nov 25, 2008 ENC

Good luck with jQuery.

Dec 2, 2008 Kevin Versteeg

Changing the value of a selectbox (or any element) in Firefox, does fire the onchange event. It just doesn't fire while the specific object still has focus. I'm not entirely sure why Firefox would do this, but a somewhat logical explanation might be the fact a browser cannot know for certain if you will keep your currently entered value or not.
<br/>
<br/>
i.e. Say value 'a' is selected, you change it to value 'b', but then back to 'a'. You might argue that the value has not effectively changed, and thus an onchange event should not be fired. Maybe that is why Firefox waits for you to drop focus on the element before firing any onchange event. Your opinon may vary.
<br/>
<br/>
By the way: as has been suggested before, you maybe should have a look at the various JS libraries available out there, like Dojo (Zend Framework integration), Prototype/Scriptaculous, jQuery etc. They tend to solve a lot of cross-browser compatibility issues you may run into. Such as your current workaround for the JS event system :)

Dec 6, 2008 Matthijs

Thank you both for the input - it once again shows how specialised the field of frontend webdesign really is, as I only know the basics of how different browsers work with a handfull of calls whereas friends of mine that are also JS guru's seem to find it the easiest task in the world to distinguish between them (hey Arjan, Piter!)
<br/>
<br />
That being said, in my experience extensive JS libraries do tend to slow down a page, considerably, hence why I avoid them where possible. Luckily for me, due to the nature of my work I have this luxury to let our front-end developers break their heads over these kind of problems ;-)
<br/>
<br/>
One point I have to insist upon however: the onChange occuring at a blur event in FireFox might be more logical, it also prevents you from using it effectively to change data while a user scrolls trough a list. If it fired the event too often there is an easy workaround (just keep a record of the last selected value and compare that). Not often enough on the other hand cannot really be solved except by also checking other triggers such as onKeyUp.<br/>
<br/>
I'm dreading the day a client comes up with a plan for a site that should also work that way on an iPod touch / iPhone ;-)

New comment

Your name:
Comment: