In A Blink

Technical Story

Dave has developed a cross-browser sprite engine, allowing users to easily drag a sprite around the screen. The library provides a browser-independent interface, taking into account browser incompatibilities regarding detection of mouse position and positioning of icons. When a new drag-and-drop requirement comes along, programmers can code to Dave's library in blissful ignorance of the underlying browser incompatibilities.

Forces

A major selling point of Ajax is portability - the ability to run an application on any platform with a modern browser

There are numerous browsers on the market.

Rarely is one browser dominant enough to be the sole target for your application. For some time, many developers targeted only the most dominant browser: Internet Explorer. However, Internet Explorer has slipped in popularity due to the rise of Firefox and Safari. Recent figures showed IE with 89% market share: still very dominant, but by no means a monopoly, and the trend is towards a more even distribution; the figure is down from 95% a year earlier. A May, 2005 report showed the following statistics:

IE: 88.86%

Firefox: 6.75%

Non-Firefox Netscape and Mozilla: 2.23%

Other: 2.06%

In some cases, particularly technical sites, the distribution is heavily skewed towards other browsers, leading to a very diverse browser base. For example, a recent survey of ajaxpatterns.org traffic (August, 2005) showed 47.5% hits from Firefox, 30.1% from IE, and 2.7% from Safari.

Browsers vary from each other in subtle and not-so-subtle ways. Sometimes, a browser simply doesn't supprt certain functionality. Other times, two browsers offer the same functionality, but it must be accessed in different ways.

While the W3C establishes standards for browsers to follow, there is no mandatory requirement and most browsers lack support in at least some ways.

Researching and testing for cross-browser compatibilities is both time-consuming and cumbersome.

When creating a web program, you want to focus on business and application logic, without being distracted by idiosyncracies of undrlying browsers. Cross-browser compatibility is a cross-cutting concern, best dealt with as a separate task at a separate time.

Google Chrome also one of the fastest web browser and getting market share very quickly

Solution

Create cross-browser components, allowing programmers to reuse them without regard for browser compatibility. A Cross-Browser component abstracts away from underlying browser issues, offering a single API which can be used on any supported browser.

Following are a couple of examples of cross-browser incompatibilities. For simplicity, only the two most popular browsers are discussed: IE and Firefox. Other browsers are also important, and not surprisingly, introduce further incompatibility issues. Following are two examples.

XMLHttpRequest: XMLHttpRequest, a critical Ajax component, is actually referenced in a browser-specific way. Most browsers include a specific XMLHttpRequest class. In IE prior to version 7, it's a special instance of the ActiveXObject class. (See below for more details.) Furthermore, there are some subtle behaviour differences. For example, XMLHttpRequest on Opera lagged behind in terms of support for features like authentication. An even greater problem is that many older browsers simply don't support this object, even though similar functionality can nonetheless be achieved using IFrames.

Opacity: Opacity - or transparency - is becoming important in Ajax applications, as discussed in patterns like One-Second Spotlight and Popup. However, portability is poor. Recent versions of Firefox, Opera and Safari allow for the CSS3 opacity style, older versions use their own different names, and IE uses a completely different approach based on a DirectX filter.

Any application using the features above must take into account cross-browser portability. Business and application logic is complex enough, without tangling it further with if-then portability statements. A better solution, and a common approach in the general area of portability, is to isolate cross-browser concerns.

Many browsers run in multiple operating systems - Windows, Apple, Linux, and often many others too. It would be nice to assume "Browser X, Version Y" was identical on all platforms, but that's simply not the case. Some apsects of browsers rely on OS-specific features, and that's where further incompatibilities arise. For example, IE's drag-and-drop capability not only depends on which version of IE is being used, but whether it's running on Apple or IE.

As a simple example, many libraries exist to make XMLHttpRequest calls portable. These libraries are examples of Cross-Browser Components, because the user doesn't have to worry about the browser being used. Most of these libraries internally use another form of Cross-Browser Component - a factory function which retrieves a suitable XMLHttpRequest object.

The function allows any code to create a new XMLHttpRequest object without worrying about browser specifics. The returned object is a Cross-Browser Component.

Note that this pattern applies as much to server-side code as browser-side Javascript. Whatever HTML is outputted from the server also needs to be portable. For that reason, you can also create server-side components that will generate portable HTML. So if you create custom JSP tags for your project, the JSP coder should be able to use them without having to make any browser-specific checks.

Decisions

What browser-specific criteria is used to create the Cross-Browser Component?

What criteria do you use to decide on a creation strategy? There are, broadly speaking, two approaches:

Version-dependent behaviour: Behaviour is based on the browser version.

Feature-dependent behaviour: Behaviour is based on checking for the existence of specific features - specifically whether a property or method exists.

The XMLHttpRequest example in the Solution above is an example of feature-driven behaviour. Before trying to create a new window.XMLHttpRequest, we check if window.XMLHttpRequest exists. An equivalent version-dependent check would do something like this:

In the above example, a function determines if the current browser is IE. Based on that knowledge, the right mechanism can be used to create an XMLHttpRequest object. How might the version be determined? There are a couple of ways. First, the navigator object reports directly on this information. Useful properties include:

Ironically, the navigator object's behaviour is itself somewhat inconsistent across versions, so you need to handle strings like the userAgent differently. If you go this route, consider a browser detection library like TechPatterns' Javascript Browser & OS Detection or Webreference's Javascript Browser Sniffer. Portability aside, the problem with direct interrogation is that the browser sometimes lies - Opera, for example, lets users manually choose which browser to report, because some sites refuse to support browsers reporting as Opera.

Version-dependent behaviour is feasible and quite common. One benefit over feature-dependent behaviour is that you only have one or two variables to deal with; with feature-dependent behaviour, you have to consider many combinations - what if the browser supports X but not Y?

However, there do remain some fundamental problems with any version-dependent behaviour. First, it's cumbersome to track all the browser versions that support a version. In many cases, you risk ruling out other browsers which may well support the feature. Also, version checks are often used in a binary way: either you're browser's supported and you can run the app, or it's not supported and you're out of luck. But if you focus on specific features, you can support progressive degradation: have a basic application that works for all browsers, with certain additional features only available to those browsers that support them.

HTMLHttpRequest

Angus Turnbull's HTMLHttpRequest is a cross-browser library for Web Remoting. Unlike many of the recent Ajax libraries, it is able to gracefully degrade to IFrame usage when executed on older browsers. The API is the same, so a programmer can access web remoting in the same way, regardless of the browser in question.

Code Examples

HTMLHttpRequest

HTMLHttpRequest is a cross-browser remoting component. It works by wrapping around a real, concrete, remoting object - either an XMLHttpRequest object or an IFrame, only one of which will be set. The construction code below makes extensive use of feature-dependent behaviour to decide, at each stage, whether to proceed with a particular strategy. There is also some use of feature-dependent behaviour to ensure that Opera and IE5 don't follow a particular path.

On-Demand Javascript

Visual Metaphor

Using a Cross-Browser Component is like working with a certified professional. The professional may have gained their certification in different ways and might offer different services, but there remains a basic portfolio of services and expectations.