Nate posted an article which coincided with Yahoo’s launch of their UI Library titled "Graded Browser Support". It appears he first coined the phrase in 2004. Subsequent google hits all point to Nate. I must admit it’s quite novel. He also posted a matrix of browser’s that Yahoo domain applications support. It’s quite refreshing to see an age old problem explored in a new way and with a catchy new phrase to help coral the thought going forward. It reminds me of some work in a previous life around WAP browser capabilities. The first generation of tool kits and support for WAP devices included huge switch statements and hacky User-Agent regular expressions. The second generation and what I belive is still in use today was a framework that detected capabilities. Rather than look for browser X and apply hacks X, the code would detect capabilities. For example the ability to support pages greater than 15k (remember we were in the mobile world), or the ability to support a password input field. The capability matrix kept the code much clearer. Instead of complex decision trees with User-Agent’s, code was clean with simple if/else statements for a particular capability. The hard part was contained in a single matrix that maps capabilities to various browsers. A quick update to the matix and a new handset could be added with little or no code changes.
The same problem has existed in web browser’s for many years. Most applications simply had isIE() or isNetscape() type checks. For the most part this worked pretty well as the capabilities being detected were generally split between the two dominant browser’s of the time; Internet Explorer and Netscape. Today the landscape is very different. No longer is the browser war a 2 horse race. For most applications on today’s web it’s at least a 3 to 4 horse race. In Nick and Yahoo’s case there are 6 different browser’s with a total of 10 browser/version combinations. This doesn’t even take into consideration the OS side of the equation. Web application complexity continues to increase. As applications take advantage of the latest features of new releases the support for capabilities in earlier versions becomes harder to represent. A simple example is the new native XmlHttpRequest object in IE7. Assuming it performs better than the ActiveX object in current releases web developers will want to take advantage of the new native object. In a isIE() type decision tree there would need to be a special case to handle IE7. However in a capabilities based application IE7 would be defined with a native XmlHttpRequest object such that the code would function without any special cases.