When to deal with browser compatibility

It is not recommended to deal with browser compatibility during the initial development of a new system. This is for the following reasons:

1. It adds a significant development overhead - When a developer works on some unit of initial functionality, they work on it in their development browser. If they have to support multiple browsers during the initial development, they are going to have to work on that same functionality that they normally would have worked out in one browser in several browsers. This obviously requires more time per unit of work.

2. Firefox and Chrome have better and faster debug capabilities - Include firebug in an HTML page that uses a debug version of a framework (such as ext-js-debug) and open that page in Firefox and then IE. You will notice that the page loads 10 times faster in Firefox. Chrome also has debug abilities natively, and in terms of Ext JS loads pages faster when using the debug framework.

3. Development time gets spent on maintenance - IE browser variants are incredibly easy to break doing things that don't cause problems in other browsers. A single trailing comma can cause an entire site to stop working in IE, and results in development time spent in chasing down something that is normally a maintenance activity.

4. Browser compatibility is easily dealt with after the fact (mostly) - Most compatibility issues are fairly simple, and therefore easily dealt with: trailing commas, console.log, bad css, and so on. It is when you start building highly customized non-standard components that browser compatibility needs to be considered beforehand.

5. Most compatibility issues come down to IE versus everything else - IE doesn't allow trailing commas, everything else does. IE doesn't support a lot of CSS 3 features, everything else does. IE doesn't provide a JavaScript console, most everything else does. What works in Chrome is highly likely to work in everything else but IE. Ultimately IE will be the browser with the compatibility issues, and is something that can be dealt with last.

The time for dealing with browser compatibility is at a milestone during the initial development where the system is mostly functionality, and the concentration moves from writing new code to fixing defects and adding enchancements. It is at this point that less code is generally being written, so it becomes less of a hassle to start figuring out why some things are not working in Internet Explorer.

Depending on the techniques used to defend against trailing commas, one will always make it through. At this point defense turns into offense. There are two types of trailing commas that produce different errors

1. Statically declared: These are trailing commas in lists that occur outside of the scope of the function, which are the most common. These are also the easiest to find, because in IE 8 or later you get a "String or numbered undefined" error that includes a line number.

Example: {1,2,3,4,}

2. In a variable in a function: These are trailing commas in lists that occur inside of a variable declaration within a function, which are the hardest to find. In the case of a framework based language like Ext JS, a line number of the error is provided, but it is at some location within the framework itself. In order to find the actual location you have to start with your primary view and start commenting out one custom component at a time until the error goes away, and then start digging into the custom component.

Example: myFunction: function() { var a = {1,2,3,4,}; }

Console Logging

Console.log is a JavaScript function used to print-out information to the browser console. The problem with this is not all browsers have a console by default, so a console.log call in those browsers results in an error that breaks the application. In particular Firefox and Internet Explorer do not come equipped with a console, but this situation is easily dealt with in the following manner:

	log: function(a) {
		try {
			console.log(a);
		} catch (er) {
			// do nothing
		}
	}
		

Define your own global log function that wraps the actual console.log in a try/catch block. In the event the browser doesn't support console.log, nothing happens.

ExtJS/Sencha works by using the idea of a theme. A language called SCSS is used to define the style of an application in a manner similar to CSS, and then the SCSS is used to generate the actual CSS to be used by the application. Once the CSS has been generated, images are "sliced" from the generated CSS to be used in browsers that don't support particular aspects of CSS.

Testing browser compatibility is a form of acceptance testing, as it usually requires a full-scale system test on the graphical user interface, which interacts with the server-side, which then interacts with the database. While the level of effort between testing every component on every page within an application and just testing the application's entry page is extremely large, the method for execution can be the same.

Selenium (http://seleniumhq.org) is a suite of tools for the automated driving of the graphical user interface of any application that displays in HTML format in a web browser. These tests can range from actions pre-recorded using the selenium web browser plug-in to tests written in Java code that execute as a JUnit test. The added advantage of this suite of tools is that it supports their execution in most every available type of web browser.

The Browser Compatibility Test

A sufficient browser compatibility test is one that just sees if the entry page of the application displays on various browsers. This is for the following reasons:

1. The most common compatibility problems result in the application not displaying at all - Trailing commas, console.log errors, and some CSS issues such as unsupported overlays all result in the same thing: the page doesn't display. The is an easy to implement method for preventing the all-to-common trailing comma from breaking an entire site for Internet Explorer.

2. Full test suites are better done after a significant portion of the system is complete - Full acceptance suites are vital for ensuring application stability, but that only applies for when the application itself has reached some point of stability. During an application's initial development it is under the most change, and trying to implement these level of tests during development adds a significant amount of overhead. This is because these tests have to be maintained, which is hard to do when the application is incomplete and being significantly changed all the time.

3. There is significantly less overhead with the entry page test - An entry page type test obviously has significantly less overhead. Worse case scenario is that you have to lookup and interact with a different field on the entry page.

4. The entry page test can apply to any system - An entry page test can simply look for a specified field on the page, and then repeat for any number of browsers. This logic applies to any system's entry page (which is typically a login page), making this generic test apply to any HTML based system.

Ideally in an existing environment the browser compatibility tests would be applied either before or after the existing acceptance test suite. The only real requirement is that the browser compatibility test can only be run against a deployed system. For more information on what it takes to setup continuous integration, see http://www.appfoundation.com/ci/

In combination with the browser compatibility test, Ext JS/Sencha is a good framework for creating HTML5 based applications and keeping them working in all browsers. It should be noted through that the browser compatibility test described works with any HTML/JavaScript based technology. The browser compatibility test is also more of a smoke test, and is not intended to replace more detailed acceptance tests. It is intended as an easy to implement and maintain method for catching the majority of common compatibility issues, in which it has proven as very effective

Ready to Start Testing Browser Compatibility?

AppFoundation has also created its own browser compatibility test that is ready to run on any Continuous Integration system, which is further described at framework.appfoundation.com. In addition, for further customized solutions contact AppFoundation.