Simple worker example in HTML5

Hi.

I just added an example of workers to the HTML5 detection and examples code on which I talked about in my two previous posts. Workers are, undoubtedly, the most interesting feature of the HTML5 specs. A lot of the specifications derive from the work done by the Google gears team. Kudos for finally bringing multi-threaded applications to the web!!!

Here's a statement on web workers in the current specifications:

This specification defines an API that allows Web application authors to spawn background workers running scripts in parallel to their main page. This allows for thread-like operation with message-passing as the coordination mechanism.

It also has the following statement:

Workers are relatively heavy-weight, and are not intended to be used in large numbers. Generally, workers are expected to be long-loved, have a high start-up cost, and a high per-instance memory cost.

Example initialization: (in parent page)
var worker = new Worker("worker.js");
worker.onmessage = function(){}

In worker.js:
postMessage();//used to send a message back to the "parent" thread.

Currently, most browsers support just strings being passed as messages, although the developers working with the W3C are also trying to get it into the specifications to pass around generic objects.

There are also some stipulations on what can be done within a worker thread:

1. Workers have no access to the DOM
2. Workers do not have direct access to the 'parent' page.

The first point above means that one cannot do any DOM manipulations within the worker thread. i.e. no access to document, window, document.body or any of the DOM elements.

The second stipulation means that the worker thread can communicate with only it's parent thread, and cannot call any functions or use any variables on the "parent" page that initialized it.

The demo I have put together works quite well in Chrome 4 and Safari 4. The demo works quite weirdly in FF 3.5, but only for the "terminate" call, where it seems to terminate the worker thread after a random period of time after I click the "Stop" button. However, that might be due to Firebug or any other extensions I may have installed. Do let me know in case you experience otherwise.

Here is the zip file once more: Html5.zip

Cheers.

Some more HTML5 tags and attributes

I've been hooked on HTML5 since I last posted on this blog. I was watching a cool video on YouTube about HTML5 features that have been defined in the specifications but do not have full support in all browsers yet. Here it is:



I updated the detection code in the sample I had posted earlier to include some new attributes and tags. I also included a simple test page that can help one determine support for input types in the various browsers. Here is is again: Html5.zip

Cheers.

HTML5 browser support

The emergence of the HTML5 specifications has gotten me all excited about the future of web pages and the possibility of web applications finally catching up with their desktop counterparts (in terms of speed and richness). For just getting my hands a little dirty with the "magical" HTML5 dust, I decided to quickly write up some sample code to detect some features I thought were important. Of course, I have skipped quite a few (I haven't read the complete specs yet).

If you want to take a look at what I've coded up, click here to download the files. The Html5Detect object queries most properties as simple getter functions.

The following table lists some of the HTML5 elements and properties supported in 4 of the latest browsers (Windows versions only tested here):

Property	Chrome4	Opera10	Safari4	Firefox3.5
canvas	TRUE	TRUE	TRUE	TRUE
canvasText	TRUE	FALSE	TRUE	TRUE
video	TRUE	FALSE	TRUE	TRUE
h264 video	probably	FALSE	probably	FALSE
OGG video	probably	FALSE	FALSE	probably
localStorage	TRUE	FALSE	TRUE	TRUE
workers	TRUE	FALSE	TRUE	TRUE
applicationCache	FALSE	FALSE	TRUE	TRUE
geoLocation	FALSE	FALSE	TRUE	TRUE
placeholder	TRUE	FALSE	FALSE	FALSE
autofocus	TRUE	TRUE	TRUE	FALSE
microdata	FALSE	FALSE	FALSE	FALSE
inputTypes.search	TRUE	FALSE	TRUE	FALSE
inputTypes.number	TRUE	TRUE	TRUE	FALSE
inputTypes.range	TRUE	TRUE	TRUE	FALSE
inputTypes.color	TRUE	FALSE	FALSE	FALSE
inputTypes.tel	TRUE	FALSE	TRUE	FALSE
inputTypes.url	TRUE	TRUE	TRUE	FALSE
inputTypes.email	TRUE	TRUE	TRUE	FALSE
inputTypes.date	FALSE	TRUE	FALSE	FALSE
inputTypes.month	FALSE	TRUE	FALSE	FALSE
inputTypes.time	FALSE	TRUE	FALSE	FALSE
inputTypes.datetime	FALSE	TRUE	FALSE	FALSE
inputTypes.datetimeLocal	FALSE	TRUE	FALSE	FALSE

For all values of "probably", I haven't tried them out myself yet, but that's the value the detection returns. "probably" indicates that the browser is fairly confident that it can play this format. IE8 doesn't support any of the HTML5 elements I've tested for.

Let me know if there are any other browsers you would like to see included in this list. For further reading, I'd recommend following the HTML5 specification itself, as it is rapidly evolving.

Cheers.

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!!!