Last week, I deployed my first ASP.NET MVC application at work. Besides being our first ASP.NET MVC app, it is also the first app where we are testing for multiple browsers; IE7 (using IE8 emulation), IE8, Firefox and Chrome. And that has taught me a number of things to watch for between the browsers. The most recent item to catch me was a difference between IE and Firefox in handling “empty” nodes.
If you have a div named “node” and you have the opening and closing tags on separate lines, the jquery statement $(‘#node’).html() will return different results in different browsers. IE returns an empty string while Firefox and Chrome return the carriage return and any spaces that might be present. Since I was checking for an empty string to trigger some processing, it wasn’t working in anything but IE. Putting the open and close tags for the div next to each other fixed Firefox and Chrome.
I get why Firefox didn’t work. In fact, I would argue that Firefox & Chrome worked correctly and that IE should not have worked. My point is that just because you test and have the site working, it doesn’t mean the site works. If you want true cross-browser compatibility, all web interface tests have to be run against all browsers.
And that begets the real problem. How do you figure out what browsers and what versions to test? The list will get very big very quickly and that gets expensive. While unit tests will help with some of this, they do have limits when it gets to exercising the interface through multiple browsers unless you buy some very expensive tools. And that’s before even considering the problem of multiple versions of IE or Firefox running side-by-side.
It shouldn’t be this hard to build an “ajaxy” web site that is compatible with the major browsers.