jQuery in Action
Understanding the browser event models
91
Affecting event propagation and semantics
There may be occasions where we want to prevent an event from bubbling any
further up the
further up the
DOM
tree. This might be because we're fastidious and we know
that we've already accomplished any processing necessary to handle the event,
or we may want to forestall unwanted handling that might occur higher up in
the chain.
or we may want to forestall unwanted handling that might occur higher up in
the chain.
Regardless of the reason, we can prevent an event from propagating any
higher via mechanisms provided on the
Event
instance. For standards-compliant
browsers, we call the
stopPropagation()
method of the
Event
instance to halt the
propagation of the event further up the ancestor hierarchy. In Internet Explorer,
we set a property named
we set a property named
cancelBubble
to
true
in the
Event
instance. Interestingly,
many modern standards-compliant browsers support the
cancelBubble
mecha-
nism even though it's not part of any
W3C
standard.
Some events have default semantics associated with them. As examples, a click
event on an anchor element will cause the browser to navigate to the element's
href
, and a submit event on a
<form>
element will cause the form to be submitted.
Should we wish to cancel these semantics--sometimes termed the default actions--
of the event, we set the return value for the handler to
of the event, we set the return value for the handler to
false
.
A frequent use for such an action is in the realm of form validation. In the
handler for the form's submit event, we can make validation checks on the
form's
form's
<input>
elements and return
false
if any problems with the data entry
are detected.
We may also see the following on
<form>
elements:
<form name="myForm" onsubmit="return false;" ...
This effectively prevents the form from being submitted under any circumstances
except under script control (via
except under script control (via
form.submit()
, which doesn't trigger a submit
event)--a common trick used in many Ajax applications where asynchronous
requests will be made in lieu of form submissions.
requests will be made in lieu of form submissions.
Under the
DOM
Level 0 Event Model, almost every step we take in an event
handler involves using browser-specific detection in order to figure out what
action to take. What a headache! But don't put away the aspirin yet--it doesn't get
any easier when we consider the more advanced event model.
action to take. What a headache! But don't put away the aspirin yet--it doesn't get
any easier when we consider the more advanced event model.
4.1.2 The DOM Level 2 Event Model
One severe shortcoming of the
DOM
Level 0 Event Model is that, because a prop-
erty is used to store a reference to a function that's to serve as an event handler,
only one event handler per element can be registered for any specific event type
only one event handler per element can be registered for any specific event type