Detecting online/offline mode in javascript

Hi.

Here is an interesting property I came across when going through some articles on object detection. With all the fuss being created recently about being able to run applications in a browser in offline mode, here is a very simple property that has been added to today's latest desktop/laptop browsers to tell if the browser is set for online or offline browsing and can aid in supporting such features:

window.navigator.onLine

This property returns true if running in online mode and false if running in offline mode.

The browsers (I've tested on a Windows Vista Home Basic laptop) that currently support this property are:

• Firefox 3.5


• Internet Explorer 8


• Google Chrome 8


• Opera 10.10


• Safari 4.0.4

Of course, check to make sure the browser supports this property before attempting to use it. Click here to quickly tell if the browser you're using supports this property and, if so, what it's current mode is.

Here's another useful method of detecting if a browser is actually connected to the internet or not using image loading:


< image src="some publicly accessible image" onload="alert('online')" onerror="alert('offline')" />


Cheers.

Speeding up javascript performance

Hi.

I came across the following video on YouTube by "googletechtalks" in which Nicholas Zakas, the principal front-end designer of Yahoo! homepage presents his finding on what kind of javascript code slows down performance in the various browsers. Kudos to Nicholas for this simple yet thought-provoking presentation. It was an eye-opener into a number of topics I never knew about and has made me think a lot more about any new JS code I write. Here it is:



In my view, the main takeaways from the presentation were:

1. Use local variables in functions for storing out-of-scope variables (in case they are to be used more than once) due to scope chains. Do not use the "with" statement and cautiously use the "catch" phrase of the try-catch blocks. Use closures sparingly due to the same reasons.
2. Data access: Accessing from object property or array item is more expensive. (object prop being most expensive). So store in local variables before using.
3. Decrease number of iterations per loop plus the amount of work being done in each loop.
4. Beware of using HTMLCollection objects (such as those returned from getElementsByTagName) as accessing their properties are very expensive. Store properties in local variables (such as length) or move into a regular object or array before accessing them.
5. Use document fragments (using createDocumentFragment) to update a group of related DOM objects and then update the page to minimize reflows (redraw of pages). Also minimize style changes to prevent reflow.

Cheers.

JavaScript window event load order

Hi.

Here's an observation I ran across when wondering about the order of event execution when registering events on a page. Let's take a look at the following code first:

< script type="text/javascript" >
/*window.onload = function(){
 sayOne();
};
window.onload = function(){
 sayTwo();
};*/
function sayOne(){
 alert(1);
}
function sayTwo(){
 alert(2);
}
function sayThree(){
 alert(3);
}
if(window.attachEvent){//specifically for IE and Opera
 window.attachEvent("onload",sayOne);
 window.attachEvent("onload",sayTwo);
 window.attachEvent("onload",sayThree);
}
else if(window.addEventListener){//all others
 window.addEventListener("load",sayOne,false);
 window.addEventListener("load",sayTwo,false);
 window.addEventListener("load",sayThree,false);
}
< /script>

If only the two commented lines at the top are uncommented (the ones using window.onload), then the "onload" event registered to "sayOne" gets overwritten by the second event handler registration to "sayTwo". Thus, only the "sayTwo" function gets executed, while the "sayOne" function will never be called.

Now, using the W3C and Microsoft event registration mechanisms, all the registered event handlers are invoked, but their orders differ in the two primary browsers viz. Internet Explorer(IE) and Firefox (FF). In IE, they seem to get pushed onto some sort of stack and the event handlers are invoked in the reverse order of them being "attached" to the window. Thus, in IE, the order of function calls on the window being loaded is:

• sayThree
• sayTwo
• sayOne

However, in FF and all other browsers (tested this code in FF 3.0.11, IE7 & 8, Opera 9.64, Safari 4 (Public Beta) and Chrome 2.0.172), the functions are called in the order in which they are registered (as in a queue). All the browsers followed the expected event order execution except IE (no surprises there)!!! Also interesting is that Opera implements both "attachEVent" and "addEventListener".

I guess this quirk is just a browser implementation decision by the companies, but I wonder what the W3C has to say about it?

Cheers.

Printing selected portions of a page with CSS

Here's a quick trick to print selected sections of a page using some simple CSS and JavaScript. This post came about after my long fascination with how maps.google.com works to produce a page that has some control buttons on it, but when the "Print" button is clicked (that just contains a simple "window.print" statement), it is able to print out only sections of the page relevant to the data we have tried to obtain. Both maps.google.com and maps.yahoo.com offer the option to print the directions and provide a preview of what the page would look like before one prints it.

Say, for example, I had the following page from which I wanted to print only sections of it out with my printer.


After reading a bit on the media attribute for CSS, I just put together a simple example to illustrate how it works. The code below displays some text and tables, some of which we want to print while the other sections we want to omit. Add the following CSS code to the head section of your page:

< style >
@media print {
.printMeNot {display:none; }
}
< /style >

Now, any sections of the page you do not want present in the printed page, wrap them in a span or a div with the class "printMeNot". That's it!!! No silly iframe methods or need to open another window with just content you want to print. This is how the print preview window would look like:


The file used in the above example can be downloaded HERE.
Browsers tested in: FF 3.0.5, IE8 Beta2, Opera 9.63, Safari 3.2.1 (for Windows) and Google Chrome 1.0.154.43.

Happy printing!!!