Events

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Douglas Crockford: In Netscape 2 we added an event model which is still in all the browsers. The browser has an event driven single threaded programming model. Which is one of the best things about the browser. Every event will be targeted at a particular node. And the events cause the invocation of event handler functions.

[00:00:25]
Unfortunately, the composition of events is really sloppy, from my perspective, there's layer confusion, there are some events which are intended for widgets, low level components, and some intended for applications, higher level components and the design of the dom mixes them all up. So you've got application level things like click and double click completely mixed up with widget level things like mouse down, mouse move.

[00:00:57]
Now it turns out they're, the silver lining here is because everything was exposed to everybody, it was possible for the libraries to come in and clean things up and impose order on it. And that worked because everything was available, but it would have been much better had they not even been necessary, if the dom had just been Designed correctly in the first place.

[00:01:21]
There are similar layer confusion in the input events. You've got application level things like blur, change, and focus and key press and widget level things like key up and key down. And again, it's all mixed up. And because it's all mixed up. I see applications mix it up, you'll see people doing all of those things all all the time everywhere because it's available.

[00:01:48]
So there are three ways of adding an event handler to a node. There is a original Microsoft model where you could say, node.onClick. Assign a function to it, done. And that still works everywhere, that's pretty nice. Microsoft decided that it should be a method. So you say node.attachMethod, onClick, function.

[00:02:08]
Okay, WC said that's not enough typing. So let's make it add event listener type f false. And this false thing is kind of weird. Normally, if you leave a parameter off the browser will replace it with undefined which is false, but in this case it really has to be false or it's gonna fail.

[00:02:30]
In a minute I'll explain how the false is used so an event handler takes an optional event parameter which is how the event knows what happened. Microsoft unfortunately didn't do that. Instead they had a global event variable which was a bad thing. So because of that this is the standard template for writing event handlers where either use the event that was passed in or you use the global variable, and the target is either gonna be the events target variable or a property or the events source, why are to names I had that it doesn't make any sense and then after that you can do your normal thing.

[00:03:16]
I don't recommend that anybody use any of what I've just shown you. [LAUGH] You don't want to use any of that because it's painful and it's it just doesn't work very well. You want to be using libraries instead.
>> Douglas Crockford: So there were two models for how to do event propagation there's the trickling model that was done at Netscape and there is the bubbling model that was done at Microsoft.

[00:03:44]
So if trickling you would start with the top of the tree and you would descend down to the tree until you get to the target node and any node along the way down can capture the event and say I'm taking care of it, don't pass it down. Microsoft, on the other hand, started with the bottom and they go up parent, parent, parent, parent until they get to the top.

[00:04:08]
And any node along the way can say I'm interested in this event, I want to handle. It turns out Microsoft got it right. That bubbling up is the correct way to do that. So when W3C went to standardize say well we need to come up with a standard for how we do the event propagation.

[00:04:27]
Do we do the trickling down or the bubbling up? They could have said let's do the one that's right.
>> Douglas Crockford: Well, why would they do that, right? So what they instead was, we'll do it both ways. We'll require that the browsers trickle down and bubble up. So they do both.

[00:04:44]
They'll first do a trickle down phase, and they'll do a bubble up phase, and that false that was on addeventlistener tells you on which phase you're doing it. False will be on the bubble up the face. So why do you even care why do they have this bubbling stuff at all?

[00:05:02]
It was to solve a problem that's probably not a problem anymore. So suppose you're making a catalog page and you've got 100 things and you can drag any of those things from a reservoir and put them onto a page and so, that's how you've got those nice authoring package that you're writing.

[00:05:21]
And so, you've got 100 draggable elements. That means you need to add a set of event handlers to each one of those. You have to add mouse down, mouse up, mouse move and so on. So that's hundreds of sets of event handlers. In 1995, that took a long time browsers were a lot slower then.

[00:05:40]
JavaScript was a lot slower then. It would take time to do all of that work. So instead what you would do is add one set of event handlers to the common parent of that hundred. And that common parent would intercept all of the events and move all the children as needed.

[00:05:59]
I don't think it matters anymore with the systems have gotten so much faster that it's in the noise, but it's still in the model see you still need to be aware of it. One thing you have to do is cancel bubbling, so at some point some node has taken care of everything and it says, please don't tell my parents, it's under control and.

[00:06:18]
And there are two ways to do that and you need to be able to do it both ways. And sometimes you want to prevent the default action after everything is down in the browser itself may want to do something. May want to submit a form or or give focus to something if you don't want that to happen, you prevent that.

[00:06:38]
And there are three ways to prevent that from happening and you have to do all of those as well.