Learning Event-Driven Programming Best Practices From Web Browsers

Very interesting. Just I hope that we don't face a different browser behavior issue, then we need also to take care of which browser client is using.

Honestly ... I hate getting deeply into these complicated details and trying my best to avoid it ... it totally confuses me.

As I saw from your nice video, JQuery is solving one issue and leaving another .. so can I say "we can't rely on JQuery always?"

But in case if I have to develop rich internet application with Ajax and user interaction ... something high level close to the huge Google Docs. Then of course I have to take care of all these things .. finally, this is my point of view :)

Your example worries me a little bit. The browser shouldn't be concerned about you falling into an infinite event loop and prevent you from firing the same event from within the event handler. I can't think of a use case now but I'm certain some kind of recursive event handling is useful in some instances. At most it should give you a stern warning message about what you're doing. In your code you assign the handler using a jQuery method but then you invoke it using native javascript which complicates matters because I know that jQuery does some gymnastics with event bubbling so it might be doing something and causing the behavior you're seeing.

An addendum to my original comment. Try the following Ben:

var focusMe = $( "#focusMe" );
 
// Bind to the focus event on the input.
focusMe.focus(
function(){
 
// Log that fact that we made it.
console.log( "User focused me!" );
 
// Re-trigger the focus event on the native DOM
// element.
//
// NOTE: We can't do this on the jQueyr wrapper or
// we'll throw the page into an infinite recursive
// loop.
focusMe[ 0 ].focus();
 
// Also, try to blur and then focus! We're doing this
// to demonstrate that the browser seems to know that
// this would be a really bad idea and prevents it
// from happening.
focusMe[ 0 ].blur();
setTimeout(function() {focusMe[ 0 ].focus();},0);
 
}
);

I've wrapped the last call to focus in a setTimeout call and I'm certain that now you will see recursive behavior. I remember sometime ago I was having some weird interactions between the different dom event levels and the solution was to wrap things inside setTimeout to give everything enough time to propagate upwards.

Sorry, but one more. I did an experiment as well using your template as a guide by setting up two input fields and trying to trampoline between the two. Similar to what you observed there is only a single back and forth. Here's the javascript code I used if you wanna mess with it. I just found a site with two input fields and messed with it using firebug so that's why the html is missing:

email_field.addEventListener(
	"focus",
	function() {
	console.log("email focused");
	password_field.focus();
	},
	false
);
password_field.addEventListener(
	"focus",
	function() {
	console.log("password focused");
	email_field.focus();
	},
	false
);

@Ben,

The reason why browsers decouple submit() and onsubmit() is so that your JavaScripts can do only one thing. It can be thought of as a logical atomism or fine granularity.

For example, suppose that you have an (input type="button") button that you want to go to a different action page from the rest of the form. You can always say this:

if (this.form.onsubmit())
	{
	this.form.action = 'alt.cfm';
	this.form.submit();
	}

You don't want to replace this.form.action unless the form's onsubmit returns true (passed validation). Otherwise, you've messed up all of the (input type="submit") buttons by overlaying the default action.

That sort of fine-grained specificity of purpose gives maximum control to the JavaScript developer.

I might add that JS isn't terribly consistent with regard to doing just one thing. If you set this.form.MyRadio[2].checked, you will automatically uncheck a different radio button in the MyRadio group. A truly fine-grained JS interface would require you to uncheck the other radio buttons in the group yourself. But in that case, the DOM-meisters decreed that consistent user interface trumps fine granularity.

In other words, doing just one thing per event or event handler, or doing more than one thing, is a tradeoff. It was resolved one way in some situations and another way in other situations.

I just thank goodness for the consistency of returning false to interdict default behavior and stop event propagation. Thank you for that, DOM-meisters.

I notice that click() behaves differently than submit().

These both yield the same result for me; the event delegate fires as expected:
$("input").eq(0).click()
$("input")[0].click()

But as you show, these do not. The second line does not fire the event delegate.
$("form").eq(0).submit()
$("form")[0].submit()

Here's a postulate: Behind the scenes, at the browser-level, submit() is a method. Calling submit() invokes the method. UI-events, on the other hand, are pure events, not methods.

I say this because jQuery has a special event code within its event.js module that triggers and raises a "submit" event for us. When we bypass jQuery in the console, are we also bypassing the event wiring?

Looking deeper into this, there are evidently browser differences in how submit "event" is handled. This applies to all events, really.

As usual, jQuery protects us from all that.

THEREFORE it would appear that, arising from this, we could say as a rule avoid calling DOM node events directly if you're using jQuery.

@Ben,

This observation might help: If the onevent() handler can prevent the default behavior by returning false or calling preventDefault(), the event() method generally doesn't call the onevent() handler. That way, you can call onevent() to decide whether to trigger event().

But you said that focus() calls onfocus(), didn't you? That would seem to be an exception that I was unaware of.

In the early days of Netscape it was easy to get into a UI loop if you called alert() from within onblur(), because the alert itself was a blur event. So you clear the alert, and it would pop up again immediately, infinitely, until you killed the browser entirely. So I got into the habit of avoiding onfocus() and onblur() for data validation.

Does focus() call onfocus() in all browsers you tested? Or just the awful one?

tell me about the software who is used for writing javascript in following video you have show in this post !

thanks !

So-So written article, if only all bloggers offered the same content as you, the internet would be a somewhat better place. Keep it up! Happy Days. j/k -- please block uggbootssale for the love of BN.COM!

Very cool post, @Ben. Always love "Best Practices" posts, esp when they may keep me from avoiding a pitfall (did you hear the Atari tones?) in the future.

@Anirudha - I think you are wanting to know more about JQuery -- http://jquery.com/

i am know about jQuery but i don't know which software they use to write jQuery in this video.

@ randall tell me the name of software they use in this video.

@anirudha,

It looks like Ben is using CF Builder here, an Eclipse-based ColdFusion editor. My guess is that he's got a jQuery plugin added that's helping with the code hints.