Thursday, February 21st, 2008

Feature Detection and Cross-Browser Widgets

Category: Articles, JavaScript

Peter Michaux has done some very thorough work on feature detection in the browser and cross browser widgets.

In his feature detection article he walks through a myriad of approaches with pros and cons:

Feature testing is not easy and there is no one right answer. From a practical stand point, the more strict your tests are the more likely your code runs only when it will run successfully.

There are some obvious wrong answers like navigator.UserAgent inference, unrelated execution inference and unrelated object inference. Check the library you are using. Does it use any of these techniques? I have seen many uses of these techniques in mainstream libraries even where there is a well known, better test available. The mainstream libraries cannot consider claiming to be state of the art until they remove these bad practices at the very least.

The above discussion focuses on tests against a single object to infer if that object or similar ones work. Sometimes it may be necessary to use multiple objects together to make an inference about one object. An example for scroll reporting. Even when using multiple host objects in a test the three isHost* functions will be useful.

Feature detection is not easy, but as professionals, we should use the best tests we can.

In his cross browser widget article he goes further to create a library to handle cross browser widgets:

Build a robust widget for the general web is hard work and the example above has room for improvement. The level of feature testing could be increased at the cost of file size. For example, on comp.lang.javascript, David Mark suggested that the browser could run out of resources and a call to createElement could return null. He also admitted this may be overly paranoid. I think it is and by testing for the existance of document.createElement I’ve inferred that calls to it will work as expected.

I’ve tried the tabbed pane in all the browsers I have and it is either enabled an works or it is disabled and doesn’t throw errors. I suspect there is a browser out there somewhere that will throw an error. That is just the nature of the cross-browser challenge. In a perverse masochistic way, I somewhat hope someone can find a browser in which this widget breaks. That is one way we can continue to improve.

Posted by Dion Almaer at 9:03 am

3.2 rating from 36 votes


Comments feed TrackBack URI

For simplicity’s sake, it seems Flash is the best platform for developing “cross-browser widgets”.

Comment by Liquidrums — February 21, 2008

I don’t know how well screen readers nowadays handle Flash, but the support used to be ultra crappy.

Also, I haven’t seen much Flash widgets where complete keyboard controls (Ctrl + Tab, Ctrl + Shift + Tab, Ctrl + Accesskey, Focus + Tab, Focus + Cursorkeys, Focus + Home, Focus + End etc. etc.) were supported. I don’t know if that’s due to an inability to implement that in a Flash widget, if it’s due to the fact that implementing it is a horrible amount of work, or if somehow most people seem unwilling to implement such things as of yet.

Next to that, most Flash widgets behave very strangely when you try to select text from the HTML document and the Flash canvas at the same time.

There are probably more accessibility/usability downsides to widgets in Flash, but these alone make them a pain to work with, in my opinion.

Comment by DiSiLLUSiON — February 22, 2008

Oh, I forgot, text zooming a page doesn’t do crap for a Flash widget when it is embedded with a specific (pixel) size. I don’t know yet if Firefox’s Page Zooming has fixed that.

Comment by DiSiLLUSiON — February 22, 2008

Leave a comment

You must be logged in to post a comment.