Events Part II Browser Variations Document / Window Events Form Events --- Using named functions (instead of anonymous)

Learning Objectives By the end of this lecture, you should be able to: – Begin to appreciate the significance/challenges of browser variability to a web developer – Understand the basics of document and window events – Understand the basics of form events and keyboard events

Okay, we need to digress for a moment… One of the biggest issues in web design is that in spite of the W3C’s best efforts at standardization, the fact remains that some browsers behave differently from others in responding to identical blocks of HTML/JS/jQuery/CSS code. In fact, one of main the reasons that jQuery was develped was because one bane of JS programmers’ existence was the hours and hours of extra coding they had to write to check for different browsers so that they could modify their code based on the way different browsers worked. In addition, even with a given browser (e.g. Firefox or Safari), different versions would be in use on different computers which would frequently respond in different ways. jQuery attempts to minimize many of these issues. When you invoke a function such as fadeIn(), there is other stuff that jQuery is doing behind the scenes to ensure that regardless of which browser you are using, the function should behave as expected. However, there remain certain types of functionality that do behave quite differently depending on which browser/version is being used. Examples of events to which different browsers/versions frequently behave inconsistently include the initial loading and unloading of web pages into the browser window, and when windows are being resized. So what do we do? Simple: For the most part, we avoid them! Okay, I may be exaggerating a little here. However, if and when you use any of these tools, they should be used with some care. Definitely do a little poking around the API and do a LOT of testing with different browsers before you go ‘live’ with a major website. Browser differences are one of the biggest issues that serious web designers spend their time and energy trying to anticipate and respond to! BROWSER WARS!!!

Document / Window Events There are a series of events that fire based on web pages being loaded into the browser window, browser windows being resized, web pages being unloaded (i.e. user clicks to another page), and so on. We’ll briefly discuss them here, although we will not delve into them very much for now. As with some of the events discussed in previous lectures, most of the time, the name of the function corresponds to the name of the event. For example, the ‘unload’ event can be matched to a function called unload(). The next couple of slides do discuss this method along with a corresponding ‘ load() ’ method. I will leave these examples in for now, but will be removing them in subsequent sessions of this course.

Document / Window Events There are a series of events that fire based on web pages being loaded into the browser window, browser windows being resized, web pages being unloaded (i.e. user clicks to another page), and so on. We’ll briefly discuss them here, although we will not delve into them very much for now. As with some of the events discussed in previous lectures, most of the time, the name of the function corresponds to the name of the event. For example, the ‘unload’ event can be matched to a function called unload(). The unload event – DEPRECATED in jQuery version 1.8 Whenever the user does something to leave the page, whether it be clicking on a link to another page, closing the browser window, or closing a browser tab this event will fire. If you do want to react to a page being unloaded, you can do so with a related function helpfully named unload() : //Note that the selector is called ‘window’ (not ‘document’) $(window).unload(function() { alert('Goodbye!'); }); This function has been used for both good and evil. On the one hand, it can be used to clean up any last minute details – particularly if there has been server-side interaction. Another popular use is to warn the user if they have failed to do something like clicking the ‘submit’ button for a form. On the other hand, this has been abused by programmers to prevent users from easily leaving their web pages! For example, they might write code that will simply open up a new window with the same page on it! Needless to say, such developers are deserving of their own private wing at Guantanamo. The unload() function behaves in different ways depending on which browser is being used. Students trying it in Firefox, for example, may find that it does not work. If you are one of these students, do not worry about it for now. We may return to the specifics at a later point.

Document / Window Events contd: The ‘load’ event The load event – also deprecated  stick with $(document).ready()

Document / Window Events contd: Resize & Scroll events The resize event Whenever the user drags their window to resize it, or if they click the maximize or minimize buttons, this event will fire. You can respond to this event with the resize() function: $(window).resize(function() { alert('Help, I\'m shriking (or growing)!'); //Note the escape character!! }); You will definitely want to be careful with this one! The reason is that in some browsers, the event fires only once per resize that the user makes. In other browsers, the event fires constantly as the user resizes the window. Imagine if you had an alert() function as the body of the resize() function. In some cases, you could end up with hundreds of alert boxes poppping up! On those occasions when this function is used, it is usually used to reformat a web page based on the new size. The scroll event This event fires whenever the user moves a scroll bar. It also typically (based on which browser!) will respond to up and down arrow keys and special keys such as home/end/page-up/page-down and so on. It may also respond to the scroll wheel of a mouse, or a two-fingered drag on a mousepad.

Form Events Forms, too, generate a series of events behind the scenes. For example, every time you click into a text box (e.g. to enter your address), a ‘focus’ event fires. The ‘focus’ event: This event fires whenever a user clicks in a text-box, radio button, checkbox, and so on. For example, you could have a little window pop up letting the user know what they want to do. The function’s name is called focus() and it’s argument is, as usual, an anonymous function. Example: Say you had a text field with an id of ‘ txtUser ’. The following code would cause the background color of the text field to become yellow: $('#txtUser ').focus(function() { $(this).css('background-color','yellow'); //Note the use of ‘this’ here //Remember that ‘this’ is a substitute for the selector. You SHOULD get used to using ‘this’ }); The ‘blur’ event: This event is fired when a form element that was previously ‘focused’ is left. So say a user has just finished typing something in an text field called ‘txt ’. When the user clicks on the next element of the form, the ‘txt ’ element will fire the ‘blur’ event. In other words, the ‘blur’ event is fired when an element is no longer infocus. Let’s use it to change the previous example (where we had the ‘txtUser ’ highlighted in yellow) to return back to white: $('#txtUser ').blur(function() { $(this).css('background-color','white'); }); The blur event is also very helpful for form validation. For example, you could write code to check to make sure that has only entered valid characters in, say, a field for phone number.

Form Events contd The ‘submit’ event: Fires when the user clicks on a ‘submit’ button. This is commonly used for form validation. That is, when the user submits the form, a script kicks in that looks through all of the form elements to make sure that all required elements have been completed, and that no invalid characterrs (e.g. for hacking purposes) have been entered. The ‘change’ event: This only works for certain form elements such as radio buttons and checkboxes. This event fires whenever the element has been changed. So if a checkbox that was previously checked is now unchecked by the user, the change event will fire. Programmers sometimes use this event to immediately react to a form event instead of the submit or blur events. Choosing submit v.s. blur v.s. change for form validation will depend on the context and various requirements. We may investigate this further down the road when we take a closer look at forms and regular expressions.

Keyboard Events Keyboard events are tricky to use because they are generated differently depending on which browser is in use. However, they do have their uses. For example, some videos allow the user to press the space bar to pause and restart. If you want to use keyboard events, you should definitely spend a little time exploring the API documentation. The keypress event This is similar to the mousedown event. That is, the moment you press a key down (and even before you release the key), this event fires. For most browsers, this event fires over and over until you release the key. If you had an online ‘shoot-em-up’ video game, you could use the keypress to, say, have a gun fire over and over as long as the user holds the key down. The keydown event This is very similar to the keypress event. However, in most browsers, it is fired only once as opposed to repeatedly. One subtle distinction from keypress is that this event is fired just before keypress. So if you happened to have code written for both of these events (keydown and keypress), you should realize that the keydown event will fire first. The keyup event Not surprisingly, this event is fired when you release the key. It is not used very often.

Unrelated Topic: Using a named function instead of an anonymous function Using an Anonymous Function A little while back, we learned how to use anonymous functions in certain situations such as reponding to events: $('selector').onclick( function() { document.write('Hello, User'); document.write(' How are you this fine day? '); } ); However, if you anticipate the possibility that you may need to use the code for your function at some other point, then you should take that code and place it inside its own function. This is nothing new – you have been placing code inside functions all along, right up until we learned aboyt anonymous functions. Using a Named Function In this case, you would take your code and placed it inside a named function (as you’ve done many times in the past): function greetUser () { document.write('Hello, User'); document.write(' How are you this fine day? '); } Now you can simply invoke the function as the argument: $('selector').onclick( greetUser );

Using a named function instead of an anonymous function contd. Using a Named Function $('selector').onclick( greetUser ); However, there is one VERY important detail that you must note. Did you spot it??? When you invoke the function as the argument to onclick (or to any event), you do NOT include the parentheses. Note that after we write the name of the function ‘greetUser’, there are NO parentheses! This is not typical behavior, and therefore may be easy to forget. It’s one of those annoying things that you simply have to remember!

Named or Anonymous? Which should you use? It depends. If you are only planning on using the code at that time and you do not anticipate using it at any other point, then it is probably better to use an anonymous function. This way, the code is right there in one place and easy to follow. If however, you anticipate the possibility of using the same code two or more times, then you should place it inside a named function.