When to set DOM events

A

André Hänsel

Hi,

from what I read it seems that the "traditional" way of registering
handlers for DOM events (element.onclick = function() {}) is currently
considered the optimal one.

But when and where shall I register my handlers?

In body onload? In DOMContentLoaded? In a script block at the end of
the page? All three appear quite cumbersome to me. So how should I do
it?

Regards,
André
 
T

Thomas 'PointedEars' Lahn

André Hänsel said:
from what I read it seems that the "traditional" way of registering
handlers for DOM events (element.onclick = function() {}) is currently
considered the optimal one.

Hardly, especially not in the case of `onclick'. The `click' event, which
it handles, bubbles, so there is no need to go about the very inefficient
business to add a listener for it to every element in sight, which may never
be touched by the user. Add it to a common parent element instead and
determine the event target. And prefer standards-compliant event methods
over the proprietary `on*' assignments, that is, use a wrapper method to
determine which one is supported first. (You'll need a wrapper for
determining the event target -- Event::target or window.event.srcElement --
anyway, thanks to M$'s unwillingness or incompetence to implement the
standard there.)
But when and where shall I register my handlers?

With a bubbling intrinsic HTML event, such as `click', or a non-bubbling
intrinsic event that is not used on more than, say, a handful of elements,
you should use the corresponding HTML attribute, e.g. `onclick'. With a
non-bubbling intrinsic HTML event that is used on more than a handful of
elements, or a non-HTML event, or a proprietary event, use a wrapper method.
In body onload? In DOMContentLoaded? In a script block at the end of
the page? All three appear quite cumbersome to me. So how should I do
it?

Depends. As a rule of thumb, do not use dynamic assignment of event
listeners, that is, one of the scripting methods describe above, if the
features you are using could work with static assignment as well. Users
will be glad that your document does not work differently (or break) in
different loading states. (That is what the "Unobtrusive JavaScript"
lemmings don't seem to get.)


PointedEars
 
T

Thomas 'PointedEars' Lahn

Thomas said:
Depends. As a rule of thumb, do not use dynamic assignment of event
listeners, that is, one of the scripting methods describe above, if the
features you are using could work with static assignment as well. Users
will be glad that your document does not work differently (or break) in
different loading states. (That is what the "Unobtrusive JavaScript"
lemmings don't seem to get.)

And, lest you forgot, you should not use client-side scripting, or you
should use client-side scripting only as a bonus feature, where and when CSS
suffices. That applies to all kinds of hover effects (such as menus and
tooltips) in particular.


PointedEars
 
A

André Hänsel

Thomas 'PointedEars' Lahn said:
Add it to a common parent element instead and
determine the event target.

That is a very good idea, thanks.
With a
non-bubbling intrinsic HTML event that is used on more than a handful of
elements, or a non-HTML event, or a proprietary event, use a wrapper method.

What kind of wrapper method do you mean?
Depends.  As a rule of thumb, do not use dynamic assignment of event
listeners, that is, one of the scripting methods describe above, if the
features you are using could work with static assignment as well.  Users
will be glad that your document does not work differently (or break) in
different loading states.

Yes, of course. This is what bothers me and made me ask this question.
I do not know any methods of "static assignment" but I'd like to. Or
do you mean the on* attributes? So you would prefer the "inline"
method to the "traditional" one?

André
 
T

Thomas 'PointedEars' Lahn

André Hänsel said:
That is a very good idea, thanks.

You're welcome. Note however, that if you do it with HTML event-handler
attributes, (AFAIK) you are forced to use the still proprietary `event'
property. It works quite reliably there (so far "cross-browser"), but you
should perform a minimal feature-test before using it anyway:

What kind of wrapper method do you mean?

Like my dhtml.addEventListener (_addEventListener()).
Yes, of course. This is what bothers me and made me ask this question. I
do not know any methods of "static assignment" but I'd like to. Or do you
mean the on* attributes?

Yes, I do.
So you would prefer the "inline" method to the "traditional" one?

I would always prefer the standards-compliant *and* reliable approach above
other approaches, if you mean that. What you call "traditional" is still
*proprietary* and *error-prone*.


PointedEars
 
T

Thomas 'PointedEars' Lahn

Thomas said:
<... on...="if (typeof event != "undefined") foo(event)">...</...>

Sorry, should be

<... on...="if (typeof event != 'undefined') foo(event)">...</...>


PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,778
Messages
2,569,605
Members
45,238
Latest member
Top CryptoPodcasts

Latest Threads

Top