I was all for throwing away my virtual machines there and then. However, I soon realised that they were as lacking as all the other cross browser testing systems out there. The most recent of which is a product from Microsoft themselves. Called SuperPreview, it is actually closely linked with the Expression product and it allows you to display the same page in different version of Internet Explorer. This is a similar approach to IETester, which allows you to open tabs containing the different rendering engines. This is fine if you just want to see that IE6 renders things in a completely different manner to everything else out there but it does not help you one bit if you are actually trying to solve those rendering problems.

Why do none of the IE cross browser rendering tools contain the Developers Toolbar? I mean, it is not a fraction as useful as the wonderful Firebug but it is the nearest we have to an IE tool that actually assists the developer in ironing out those css problems. I have even resorted to the IECollection which claims to contain all the versions of Internet Explorer that have ever existed and to contain the developers toolbar but only manages to throw up error messages and still no sign of a working developer’s toolbar.

So here it is, a request to the producers of the current cross-browser products or to anyone who fancies the challenge. Create a tool that is actually useful. Make it contain all current browsers and some developers tools that allow real-time changing of CSS and whilst your there, make it highlight the padding and margins in that oh-so useful way that Firebug does. That way we can actually see what is causing the problem and try a few fixes without having to change the css file and refresh the page every time. Also, do a favour for the Mac users out there and make it cross-platform.

If it really was a useful tool, developers would buy it and most be willing to pay a substantial license fee. I spend an awful lot of the time waiting for virtual machines to boot and suffering the performance consequences of running them whilst developing, so I would be happy to fork out some cash to solve this problem.

There have been two incidents recently however, that have made me realise that my crash course on jQuery selectors has been missing something vital. The first was when I found some time to explore the options of profiling some of our javascript code. When I first started this, the only option I could see was John Resig’s deep profiling script that injected the statistics at the bottom of the page. This had some limitations however, and I was very happy to open my news feeds soon after and find that he had added a couple of extra methods to FireUnit that enabled you to profile javascript function calls.

What I noticed straight away was that there were a lot of seemingly simple calls in our code that took a long time to execute. The reason for this was that the selectors were vague:

    $('.myclass').somefunction();

In order to find all the matches, even if there is only one, jQuery needs to traverse the entire DOM looking for any element that might have the matching class, and that takes time. By narrowing down the selector using, for instance, the type, jQuery can very quickly eliminate all other types. This speeds things up a lot.

The second incident was due to another ‘benefit’ of being a tech lead. I tend to get passed the most peculiar and hard to diagnose bugs. The bug in question was on a page that contained two autocomplete text boxes, one of which was part of a compound control. The bug manifested itself by not being able to select an item from the second autocomplete text box properly. I was handed the bug with the information that it seemed to happen only when you selected from the first autocomplete control first. Needless to say, there was a lot of poking around in the code of both the autocomplete and the compound control, which is particularly complex given the nature of the control.

Thanks to firebug‘s great console logging, I discovered that the variable that contained all the autocomplete list items seemed to be a combination of both controls. It was not too long before i discovered the code that caused the problem:

    listitems = $('.auto').children('li');

There was nothing mysterious going on at all, jQuery was asked to select all of list items in both controls, so it did.

What had happened in both of these incidents is that I had failed to mention the importance of an accurate selector in jQuery during my crash course. The new developers were blissfully unaware of the consequences of not specifying exactly which elements you want jQuery to select. What I had also failed to emphasise was another way of narrowing down and speeding up the jQuery selection – by use of the elements that you already have. In the case of the autocomplete, we already had a reference to the list itself, so it was simple:

   listitems = thelist.children('li');

This not only eliminated the cross-contamination of the two controls but seeded things up. So the rules to keep things fast and to save me headaches are simple:

• Use a selector that very accurately matches the elements you require
• Utilise references to elements you already have

I like to keep my computer as lean and mean as possible and installing all the browsers frustrates me. On top of that, one must keep an additional installation of XP as a virtual machine, just to test IE6. Don’t get me wrong, I cheered at the day that IE Tester was released but unfortunately progress on that project is slow and bugs are large, so the virtual machine tends to win.

Today all that changed for me. I came across Xenocode, who are in the virtualization space. Instead of creating entire virtual machines, OS and all, Xenocode software allows you to create a virtual environment for a single piece of software. This means that everything that is required to run that piece of software is all neatly wrapped up in a bite-sized executable. So what does this mean? All the major browsers as single executables. Awesome.

Just click on the browser you want, download the executable and run it. No more installing or virtual machines to clog up your machine.