• Introduction
• Multiple grades
• CSS
• Javascript
• Images
• HTML
• Summary

Introduction

Front-end web-development is very different from working on the server-side, where you typically have complete control of the system, and you need produce code for only one environment. Front-end developers, however, face the prospect of being required to develop for many different environments, over which they have very little control due to the different implementations of the various specifications that web-browsers use.

In 2006, Nate Koechley from Yahoo introduced Graded Browser Support (GBS), a principle which is now followed by a huge number of professional developers. When a developer is creating a web-site or a web-application, they will ensure that the core functionality of the site (viewing content, filling in forms etc.) is available to as many browsers as possible, but without any 'flashy' extras. This is core (C grade) support. Certain features can then be added to the site (through progressive enhancement) for browsers which have the required capabilities needed for these features, thus making up first class (A grade) support.

A browser is normally included into a particular grade when it has a large enough market segment in the target market, and is known to have the capabilities that the developer requires for a particular site or application. However, we must also consider the fact that a browser can be placed in any one of many different configurations by the end user. For example, a browser might have Javascript disabled, or images set not to show, and so on, which will change the support grade. To this end I propose extending the GBS method to be technology dependent, from which the browser support grade can then be derived. This extended method is termed Graded Technology Support (GTS).

Note that I do not propose that the grades I present in this article are correct for all projects (indeed, the support levels should be clearly written up in any documentation you produce for a particular web-site, and the reasons for deciding on them), but are merely a basic guideline.

Multiple grades

One of the big advantages of splitting a browser support grade into technology dependent grades is that it will take account of user configurations. It also allows the developer to introduce new technologies into the support matrix very easily, for example SVG and MathML. Furthermore, it will quickly take account of browsers which have a low market share, but have have the required capabilities for one particular area.

I believe it is wrong to lump all requirements into one single grade. For example if I configure Firefox 2 to have Javascript disabled, then I would still expect to receive A grade CSS (this discussion arises from the excellent work done by Filament Group on progressive enhancement in CSS).

Typically front-end developers work with four distinct technologies, which I will discuss in this article:

• CSS
• Javascript
• Images
• HTML

For each browser, and then each configuration of the browser, a grade is assigned to these technologies. I will limit the scope of browsers that I consider in this article, but the list can be readily expanded (or contracted) as required. The support grades used are:

• A grade: First class support with all widgets
• C grade: Core support, with basic information only information
• X grade: Feature/code blocked from the browser
• U grade: Unsupported. The browser will receive whatever the listed C grade browsers would, and then interpret that as it can.

By assigning each technology a particular grade we can construct a support string of the four letters (in the order of the above technologies list), for example AAAA, or AAXA (no images), etc. From this the browser support grade can then be derived by taking the lowest grade in the string. For example a ACAA browser would be C grade overall. Furthermore, note that this particular browser would receive only basic Javascript support, but would get A grade CSS, despite it's overall grade.

The table below shows a break down of the technology support grades that I use as a typical starting point when working on a new project (remember that user settings in the browser can influence each grade). The rules for deciding what grade each browser gets for the individual technologies are discussed in the following sections.

Browser	Version	CSS	Javascript	Images	HTML
Internet Explorer	6	A	A	C	A
Internet Explorer	7	A	A	A	A
Firefox	2	A	A	A	A
Safari	3	A	A	A	A
Opera	9.2	A	A	A	A
All others	-	U	U	U	U

CSS

CSS has long been the bane of front-end developers, not through any problem with the specifications, but rather with the widely different implementations of the specifications. My main method for deciding what support grade the different browsers should receive is based on the market share of each browser. If the browser has a large enough market share, then it is worth spending the time to ensure your site will display correctly on it.

As you will be able to see from the support table, I typically only support A grade CSS browser for any CSS. As a different, and more in-depth example, this table shows the browser support grades we use at U4EA for the project I am currently working on (this is very much a fringe case!). Of course, Conditional-CSS makes these support grades much more attainable!

Javascript

There is a plethora of Javascript libraries which are available, including the outstanding jQuery and YUI libraries, which will abstract out most of the variations in browser implementations of Javascript, however, I still have a few base rules which I apply to determine a browser's Javascript support grade:

• A grade Javascript:
  • If we can make asynchronous server requests
  • If Function.call is available
  • If Array.shift is available
  • The browser must support all C grade requirements
• C grade Javascript:
  • If document.getElementById is available
  • If document.createTextNode is available

Images

Typically we will throw images into a web-site without really thinking about them, or whether the browser will display them correctly or not. There are fringe browsers which are very rarely used such as Lynx and Links, and will simply not show images at all, thus receiving X grade support if we included them on the support grid. In addition to this, there might be some visitors to your site who switch images off on purpose (still on a dial up connection for instance), or the format simply might not be correctly supported by the web-browser. The following is the criterion I use for browser image grades:

• A grade images:
  • Alpha channel PNG image support
  • The browser must support all C grade requirements
• C grade images:
  • JPEG image support
  • GIF image support

HTML

It might seem odd to include HTML in this list, as most developers will barely give the availability of this technology a second thought. This is perfectly valid and reasonable with all relatively modern browsers, however, for completeness, we include it here. The condition for A grade HTML support is that HTML 4 or newer is required for the browser (anyone going back further than HTML 4 is much braver than me, and must have a very good reason!). Note that we don't give anything but A grade HTML here, as all other browsers are unsupported (U grade).

• A grade HTML:
  • HTML 4 or XHTML 1 must be supported to an acceptable degree

Summary

I've presented in this article, an extension on the graded browser support methodology, which considers individual support grades for the different technologies a front-end developer uses. This reflects my understanding of progressive enhancement techniques, and the way I plan browser support when I start a new project.

Questions / opinions? Please free feel to get in touch!