An event can have only one event handler attached to it (or so it seems)

Marcy’s page has a problem. We’ve assigned two event handlers to the onmouseover property of her image buttons:

Only the LAST event handler assigned gets run

When you assign two event handlers to the same event, only the last event handler that’s assigned gets run. So on Marcy’s page, mousing over a button triggers onmouseover. Then, that event runs the last handler assigned to it: buttonOver().

Event handlers are just properties

When you assign an event handler to an event on an XHTML element, the handler becomes a property of the element, just like the id or title properties of an <a> element:

A property can have only ONE value

If you assign a value to a property, that property has that single value. So what happens when you assign another value to that property? The property then has the new value, and the old value is gone:

Assign multiple event handlers with addEventListener()

So far, we’ve been adding event handlers to elements by setting the event property directly. That’s called the DOM Level 0 model. DOM stands for the Document Object Model, and it’s how elements on a web page get turned into objects our JavaScript code can work with.

But DOM Level 0 isn’t cutting it anymore. We need a way to assign more than one handler to an event, which means we can’t just assign a handler to an event property. That’s where DOM Level 2 comes in. DOM Level 2 gives us a new method, called addEventListener(), that lets us assign more than one event handler to an event.

Here’s what the addEventListener() method looks like:

Brain Power

In what order do you think the browser will call your handlers? Do you think the ordering in which the handlers are run will affect how you write your code?

There are no Dumb Questions

Q:
Q: DOM? What’s that?
A:
A: DOM stands for the Document Object Model. It’s a specification that defines how the parts of a web page, like elements and attributes, can be represented as objects that your code can work with.
Q:
Q: And what does Level 0 mean?
A:
A: Level 0 was actually an interpretation of the DOM published before the DOM was formalized. So it works with the DOM but isn’t really part of it.
For your purposes, though, DOM Level 0 is what your browser uses to come up with basic objects and properties for each element in a web page. When you assign a handler to an element’s onmouseover property, you’re using DOM Level 0.
Q:
Q: What about DOM Level 1? Do I need to worry about that?
A:
A: Not right now. DOM Level 1 has to do with how you move around in a document. So DOM Level 1 lets you find the parent of an element, or its second child. We’ll look at DOM navigation quite a bit in Chapter 6.
Right now, though, you don’t really need to worry too much about what level of the DOM you’re using, except to make sure your browser supports that level. All major browsers support DOM Level 0 and Level 1, which is why you can assign event handlers programmatically using event properties like onclick and onmouseover.
Q:
Q: And addEventListener() is part of DOM Level 2?
A:
A: Exactly. DOM Level 2 added a lot of specifics about how events should work and dealt with some XML issues that aren’t a problem for us right now.
Q:
Q: So I can use addEventListener() to add multiple events, and it will work with all the browsers?
A:
A: As long as they support DOM Level 2. But there’s one major browser that doesn’t support DOM Level 2... we’ll look at that in just a minute.
Q:
Q: Couldn’t I just assign an array to an event property, and give the property multiple values that way?
A:
A: That’s a good idea, but it’s the browser that connects events to event handlers. If you assigned an array of handler names to an event property, the web browser wouldn’t know what to do with that array.
That’s why DOM Level 2 was put into place: it provides a standard way for browsers to deal with multiple events. Ideally, specifications standardize a process and remove any possible guesswork.
Q:
Q: Why are the event property names different than the names you pass to addEventListener()?
A:
A: That’s another great question. That’s just the way the authors of the DOM decided to handle event names. So if you’re assigning an event property, use onclick or onmouseover. With addEventListener(), use click and mouseover.
Q:
Q: What’s that last parameter you’re sending to addEventListener()? And why are you setting it to false?
A:
A: That last parameter indicates whether you want event bubbling (false) or capturing (true). We’ll talk more about capturing and bubbling in a bit, so don’t worry about this too much. For now, always pass false to addEventListener(), which indicates you want event bubbling.

You can assign as many handlers as you want to an event using addEventListener().
addEventListener() works in any web browser that supports DOM Level 2.

Your objects can have multiple event handlers assigned to a single event in DOM Level 2

The most important thing that DOM Level 2 added to events is the ability for an event to have more than one handler registered. You’ve already seen how addEventListener() adds a handler to an event:

The browser runs every handler for an event when that event is triggered

When an event is triggered by a mouse movement, the browser looks up the right event. Then, the browser runs every event handler function registered to that event:

Watch it!

Event listeners aren’t called in any particular order.

You might think that the browser calls the event handlers in the order they’re added, but that’s not guaranteed. Make sure that your handlers don’t depend on the order in which they’re called.

What’s going on with Internet Explorer?

The yoga page works great on Firefox, Safari, and a lot of other browsers... but something’s definitely wrong on Internet Explorer:

You can’t control what browsers your users are working with.
It’s your job to build cross-browser applications... and always test your code in LOTS of browsers.

Internet Explorer uses a totally different event model

Remember that addEventListener() only works on browsers that support DOM Level 2? Well, Internet Explorer isn’t one of those browsers. IE has its own event model and doesn’t support addEventListener(). That’s why Marcy got an error trying the yoga page out on IE.

Fortunately, IE provides a method that does the same thing as addEventListener(). It’s called attachEvent():

attachEvent() and addEventListener() are functionally equivalent

Even though the syntax is different, these functions do exactly the same thing. So you just need to use the right one for your users’ browsers.

The browser wars are just part of web development.

Like it or not, not all browsers are the same. Besides, when Microsoft came up with their own event model, it wasn’t that obvious that the DOM Level 2 would take off like it did.

And no matter how it all happened, you can’t write off people who use IE... or those who don’t.

There are no Dumb Questions

Q:
Q: So this is all about which browser is better?
A:
A: No, it’s just that not all browsers were developed the same way. It wasn’t so long ago that the DOM wasn’t a sure thing, and Microsoft just decided to go in another direction. IE isn’t better or worse than other browsers; it’s just different.
Q:
Q: Yeah, but everyone knows IE’s a pain. I mean, come on...
A:
A: It’s true that lots of web developers think that IE is hard to deal with. That’s just because it uses some different syntax. But look at things the other way: if you’ve been writing code on IE all your life, then it’s really Firefox, Safari and Opera that are a pain.
Either way, you’ve got to write web apps that work on all major browsers, or you’re going to miss out on a ton of users.
Q:
Q: Why does attachEvent() add the “on” back to the event name?
A:
A: That’s just the way IE decided to implement that method.
Q:
Q: What about that last argument to addEventListener()? Where did it go on attachEvent()?
A:
A: You may remember that the last argument to addEventListener() indicated whether you wanted event bubbling (false) or event capturing (true). IE only supports event bubbling, so that argument isn’t needed.
We’ll come back to capturing and bubbling once we’ve got Marcy’s app working on all major browsers.
Q:
Q: So which one should I use? addEventListener() or attachEvent()?
A:
A: Good question. If you think about it and look back at the createRequest() function, you probably already know the answer...

In IE, event names have “on” in front, for example, “onclick” and “onmouseover.”
In Firefox, Safari, and Opera, event names DON’T have “on” in front: “click” and “mouseover.”

Hint

The expression (document.someFunction) returns true if a browser supports running someFunction(), and returns false if that function isn’t supported.

addEventHandler() works for ALL apps, not just Marcy’s yoga page

So where should you put your code for addEventHandler()? We’ll use it in Marcy’s yoga page, but it’s really a utility function. It will work for all our apps and in any browser. So go ahead and add your new code to utils.js, so we can reuse it in later web apps we build.

Anytime you build cross-browser utility functions, store those methods in scripts that you can easily reuse in your other web applications.

Let’s update initPage() to use our new utility function

Now we need to change initPage(), in schedule.js, to use addEventHandler() instead of addEventListener(). Go ahead and make the following changes to your copy of schedule.js:

Use an alert() to troubleshoot

Without any error messages, it’s hard to know exactly what’s going on with Internet Explorer. Try putting in a few alert() statements in the event handlers, though, and you’ll see they’re getting called correctly.

function buttonOver() {
  alert("buttonOver() called.");
  this.className = "active";
}

function buttonOut() {
  alert("buttonOut() called.");
  this.className = "";
}

So what else could be going wrong?

The event handlers are getting called, so that means that addEventHandler() is working like it should. And we’ve already seen that the code in the handlers worked before we added the rollovers. So what else could be the problem?

What do you think the problem could be? Can you figure out why the code isn’t working like it should?

“this” refers to the owner of the executing function.

The this keyword in JavaScript always refers to the owner of the function that’s executing. So if the method bark() was called by an object called Dog, then this in bark() would refer to the Dog object.

When you assign an event handler using DOM Level 0, the element with the event is the owner. So if you did tab.onclick = showTab;, then in showTab(), this would refer to the tab element. That’s why showHint() and hideHint() worked great in the last chapter.

Note

“owner” and “caller” aren’t the same. In a web environment, the browser calls all the functions, but objects representing elements on the page are the owners of those functions.

In DOM Level 2, an event is still the owner of its handlers

When you’re using DOM Level 2 browsers like Firefox, Safari, or Opera, the event handling framework sets the owner of a handler to the object that handler is responding to an event on. So you get the same behavior as with DOM Level 1. That’s why our handlers still work with DOM Level 2 browsers.

But what about IE?

Event handlers in IE are owned by IE’s event framework, NOT the active page object

You already know that IE doesn’t implement DOM Level 2. IE has its own event handling framework. So in IE, the event framework owns the handler functions, not the object on the XHTML page that was activated with a click or mouse over. In other words, this in showTab() refers to the IE event framework, not to a tab element on Marcy’s yoga web page.

Note

Framework just means a set of objects or code that performs some task, like handling events on a web page.

There are no Dumb Questions

Q:
Q: What object does this refer to in the IE framework, then?
A:
A: this always refers to the owner of the function that’s currently running. So in an event handler under IE’s event framework, this points at one of the framework’s objects.
It really doesn’t matter what that object is because it’s not all that useful. What we need is a way to get information about the element that the event occurred on.
Q:
Q: But if this is how IE handles events, how did our code work back in Chapter 3 on Internet Explorer?
A:
A: Our code worked in IE because we were just using DOM Level 0 syntax. Anytime you assign a handler to a property, like currentBtn.onmouseover = showTab, that’s DOM Level 0.
But our code now is using addEventListener() and attachEvent(). That’s not DOM Level 0, and now this doesn’t mean the same thing as it did in that earlier code.
Q:
Q: Ok, great. So the page still doesn’t work in Internet Explorer. What now?
A:
A: Well, take a moment to think about what exactly you need. It’s not so much the this keyword that’s important, but the information that keyword let us access.
What exactly do we need to know about in our event handler functions?

attachEvent() and addEventListener() supply another argument to our handlers

One of the cooler things about JavaScript is that you don’t need to list all the arguments that your functions take when you declare that function. So even if your function declaration is showTab(), you can pass arguments to showTab() when you call it.

The bad thing about that is sometimes you miss out on arguments that are passed to your function.

Your event handlers get an Event object from attachEvent() and addEventListener()

When you register an event handler using DOM Level 2 and addEventListener(), or attachEvent() and IE, both frameworks pass your event handlers an object of the Event type.

Your handlers can then use this object to figure out what object on a page was activated by an event, and which actual event was triggered.

There are two properties in particular that are really helpful to know about. The first is type, which gives the name of the event that was triggered, like “mouseover” or “click.” The second is target, which gives you the target of the event: the object on the page that was activated.

Event objects know what object triggered them and what type of event they are.

Note

So we need to get access to the Event object in our handler functions.

We need to name the Event argument, so our handlers can work with it

You don’t have to list all the arguments a JavaScript function gets. But if you want to actually use those arguments in the function, you do need to list the arguments. First, we need to get access to the Event object in our handlers, so we can figure out what object on a page triggered a call to our handler. Then, we need to list the argument for that Event object:

Brain Power

With DOM Level 2 browsers, you can use either this or the Event object passed into an event handler to find out what element was activated. Do you think one approach is better than the other? Why?

You say target tomato, I say srcElement tomato...

The good news is that both IE and DOM Level 2 browsers make the object that triggered an event available. The bad news is that DOM Level 2 and IE use different versions of the Event object, each with different properties.

In some cases, the Event object properties refer to the same thing, but the property names are different. And to make matters worse, modern versions of IE pass in an Event object, but earlier versions of IE make the Event object available as a property of the window object.

Browsers that support DOM Level 2, like Firefox, Safari, and Opera, pass an Event object to event handlers. The Event object has a property named “target” that refers to the object that triggered the event.

Internet Explorer 7 passes an Event object to event handlers. The Event object has a property named “srcElement” that refers to the object that triggered the event.

Earlier versions of Internet Explorer provide the object that triggered an event in a property named “srcElement,” available on the window object.

There are no Dumb Questions

Q:
Q: So “this” always refers to the function that called my function?
A:
A: No, this refers to the owner of the function. Sometimes that’s another bit of code, but it also might be an object, like a tab on a form that got clicked.
Q:
Q: But that’s not true in Internet Explorer, right?
A:
A: this still refers to the owner of a function in IE. The difference is that when you use attachEvent(), the owner of your function is an object in IE’s event handling framework and not an object on your web page.
Q:
Q: So we shouldn’t ever use “this” in Internet Explorer?
A:
A: Actually, this is still a very useful part of JavaScript, whether you’re using IE or a DOM Level 2 browser. But if you’re writing an event handler function, you’re probably better off avoiding this. If you’re writing an event handler that’s going to be called using the IE event handling framework, via attachEvent(), then you’ve got to avoid using this.
Q:
Q: I’m still a little fuzzy on all this DOM stuff. Can you explain that again?
A:
A: DOM, or the Document Object Model, is how a browser represents your page as objects. JavaScript uses the DOM to work with a web page. So every time you change an element’s property or get an element with getElementById(), you’re using the DOM. That’s all you really need to know right now, but we’re going to dig into the DOM a lot more in just a few chapters.
Q:
Q: As long as I use addEventHandler(), I don’t have to worry about all this DOM stuff, though, right?
A:
A: Well, you don’t have to worry about whether you should use attachEvent() or addEventListener(). But as you’ll see in Chapter 6, there’s still a lot of DOM work you’ll end up doing.
addEventHandler() takes care of registering an event handler to an event in a browser-neutral way. In other words, addEventHandler() works with all modern browsers.
Q:
Q: And that’s why it’s in utils.js, right? Because it’s a utility function?
A:
A: Right. addEventHandler() works for all browsers and many different kinds of applications, not just Marcy’s yoga page. So it’s best put into a reusable script, like utils.js.
Q:
Q: But even if we use addEventHandler(), we’ve still got these issues with target and srcElement, right?
A:
A: Right. IE 7 passes off to event handlers an Event object with a srcElement property that points at the object that triggered the event. Older versions of IE make that same object available through the window.srcElement property. DOM Level 2 browsers provide an Event object with a property called target pointing to the object that triggered an event.
Q:
Q: I’ve heard that object called an “activated object” before. Is that the same thing?
A:
A: Yes. An activated object just means an object that represents an element on a web page that an event occurred on. So if an image is clicked, the JavaScript object that represents that image is the activated object.
Q:
Q: Since addEventHandler() took care of adding events on all browsers, why don’t we just build another utility function to deal with all this target/srcElement stuff?
A:
A: Now that is a great idea!

The DOM provides an object-based model of your web page that your code can work with. getElementById(), the document object, and the onclick property are all aspects of using the DOM in your code.

So how do we actually GET the object that triggered the event?

The best way to deal with differences in how IE and DOM Level 2 browsers handle events is another utility function. Our handler functions are now getting Event objects, but what we really need is the activated object: the object representation of the element on the page that the event occurred on.

So let’s build a utility function to take the event argument we get from those browsers, and figure out and return the activated object:

Exercise

You need to update Marcy’s code again. In all of the event handlers, you need to use getActivatedObject() to get the activated object. You’ll also need to change the rest of those methods to use the object returned from that function instead of this. There are a few other changes you should already have made, too. Check off each task once you’re finished.

Update utils.js
Add the addEventHandler() and getActivatedObject() functions to the file.
addEventHandler()
getActivatedObject()
Use addEventHandler() instead of addEventListener()
Use the generic addEventHandler() to abstract out DOM Level 2 and IE event handling differences.
Update initPage() to only use addEventHandler()
Use getObject() instead of this
Update all your event handler functions to use getActivatedObject() instead of the this keyword. You’ll need to make other changes to get those functions working as well.
showHint()
hideHint()
buttonOver()
buttonOut()
showTab()

When you think you’re done, try things out for yourself. Then, turn the page to see how we updated the code in schedule.js and utils.js.

Head First Ajax by Rebecca M. Riordan

Chapter 4. Multiple Event Handlers: Two’s company

An event can have only one event handler attached to it (or so it seems)

Only the LAST event handler assigned gets run

Event handlers are just properties

A property can have only ONE value

Assign multiple event handlers with addEventListener()

Brain Power

Your objects can have multiple event handlers assigned to a single event in DOM Level 2

The browser runs every handler for an event when that event is triggered

Watch it!

Note

What’s going on with Internet Explorer?

Internet Explorer uses a totally different event model

attachEvent() and addEventListener() are functionally equivalent

Hint

addEventHandler() works for ALL apps, not just Marcy’s yoga page

Let’s update initPage() to use our new utility function

Use an alert() to troubleshoot

So what else could be going wrong?

Note

Event handlers in IE are owned by IE’s event framework, NOT the active page object

Note

attachEvent() and addEventListener() supply another argument to our handlers

Your event handlers get an Event object from attachEvent() and addEventListener()

Note

We need to name the Event argument, so our handlers can work with it

Brain Power

You say target tomato, I say srcElement tomato...

So how do we actually GET the object that triggered the event?

Don’t leave empty-handed

It’s yours, free.

Check it out now on O’Reilly

Q:	Q: Why didn’t we use a try...catch block this time?
A:	A: We could have, but unlike `createRequest()`, this function doesn’t need an error to know that something went wrong. Using `document.attachEvent` and `document.addEventListener` works just as well. Besides, the `if`...`else if` block is a lot easier to read.