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.
One reply on “Graded Browser Support”
Hey Kevin, thanks for the post!
I’m glad you picked up on the Graded Browser Support stuff. It was a bit buried with all the other stuff we released today, but I plan to shine some more light on it in the near future.
I think you’re exactly right. It’s a problem that’s getting more challenging even as browsers become more powerful and faithful to web standards. I’m not a marketing guy, but you’re right that a new language is helpful to “coral the thought going forward” as you say.
We — myself and several colleagues — coined the term as far back as ealry 2003. I’ve mentioned it in passing during a few public presentations over the years, but this is the first time I’ve been able to really put the idea out there. So thanks for noticing, I appreciate it.