1. Always test in FF, IE7, Safari, Chrome and Opera the smallest HTML, CSS and JavaScript changes. Hitting F5 and testing the changes in all 5 takes less time than debugging, fixing or refactoring later. That’s learnt the hard way. Even when under pressure and tight deadlines - always do it. Let your manager know that it is a ‘must-do’ step which cannot be skipped.

2. Get IE 6 on board. While they say it’s dead, it’s still very popular (~13% in Australia). I know many developers skip IE6 testing because it’s hard to find a machine with IE6 installed. However, Microsoft gives you a neat and easy (also free of charge) way to do that:

• Download and install Microsoft Virtual PC
• Download Internet Explorer Application Compatibility VPC Image with IE 6

There is a VPC for Mac users, but I don’t know anything about it, so cannot recommend.

3. Forget about IE 8 for the next year or two. It’s good to test if you have free time available, but it’s a waste of time if you are under pressure.

4. Even if you support IE only, still do the testing for other browsers. The requirements may change and the amount of work to fix the issues can become crazy pretty soon. And these issues are very difficult to fix and difficult to test. Also not so many developers are willing to do such things, so for managers and architects it makes a lot of sense to make cross-browser testing not optional, but a mandatory procedure for both developers and QA engineers.

5. Don’t rely on IE 7 “compatibility mode” it is not working as you would expect. Now Microsoft creates another problem for us with these compatibility modes. You can get a bug report describing “IE 7 issue” because someone tested the application from IE 8 using the compatibility mode and you waste hours trying to reproduce it on IE 7.

6. QA engineers always need to do cross-browser testing after they detect an issue. A developer can save a lot of time if she knows exactly that the problem exists only in a specific browser. Make it mandatory for QA person to implicitly confirm that the issue is not a problem in other browsers (if this is the case).

7. Never rely on QA people (and end customers) in finding and testing such cross-browser issues. They might help you, but you are the only one to see the problem right away and fix it without doing another expensive cycle. QA teams even in the best shops regularly fail to do such testing.

8. Some people are trying to build ‘pixel perfect’ sites. Don’t do it. Let managers and business people know unless they want to pay crazy money for development and maintenance, “pixel perfect” stuff is not going to work in real life. If you need ‘pixel perfect’ solutions, choose another technology (flash, silverlight, whatever…) not HTML with CSS. I would love to tell a bit more about “IE6 1px misalignment” bugs I have been assigned to, but maybe in another article

9. Use cross-browser reliable JavaScript framework even for the simplest things, such as getting element by id or setting element’s style attributes. The world’s best teams put years of work into the code, you would be crazy not to use it.

10. Intel engineers cannot tell how efficient the assembly code is by just looking at it, it needs to be actually executed and benchmarked, and these people are very smart. Don’t ever expect to know how your front-end thing gonna look like. Always do the testing. Test, test, test…

I have seen the access statistics from one of the largest ISP in Australia. It almost duplicates the wikipedia’s information:

However the numbers are a little bit different:

First of all, the small number of chrome and safari browsers is a suprise, not a big one though. Also the IE still has the biggest share in the market, which comes as no suprise to me. Also the IE6 still holds a significant position (~13%) and must be taken seriously for the next year or two.

JavaScript doesn't have a handy sleep() or wait() or delay() function to pause the execution for a few seconds, so we can use setTimeout() function to emulate such behaviour. It's not straightforward and may require you to refactor the workflow, but it's delaying the execution and is really simple:

To make JTidy work correctly with UTF-8 strings and process international characters in a proper way, use the following code: