The real point we’re trying trying to make is that if you simply serve up a whole pile of complex css and js and don’t manage what happens to devices that will misunderstand this code, you are leaving a lot of people out in the cold. We believe the web should be about providing content and functionality to everyone, not just the latest and greatest versions of popular browsers.

The world we’re coding for is getting more diverse and complex, not simpler because of the wide range or mobile phone, interactive TV, kiosks, gaming devices that are coming into the market with web access and “non-standard” rendering or js support. When you add to this environment the need to support those with disabilities and achieve section 508 compliance, we don’t feel that it’s responsible to “basically disregard any browsers incapable of handling such basic standards”. Even though they may not be using FF 2 or IE 7, these are still real people (and potential customers) and turning them away because you wanted to use a js-dependent widget or complex CSS layout is really not an acceptable option.

Because Filament Group tends to specialize in building rich web apps, not simple content sites, we have made the choice to start by serving up a page that uses clean, semantic html, css (and sometimes a bit of js) that we believe will work everywhere. We keep the code as lightweight as possible because many people have slower web connections and less memory. If the client passes the test, we can feel more confident that layering in all the code for a richer experience will not case rendering or functionality issues. We want to play it safe with which browsers pass because it would be a shame for a device to receive a perfectly usable lo-fi version, then be upgraded to the hi-fi version and have some little css or js issue make the site unusable.

This approach is admittedly a work in progress (and it’s great to hear all the interesting dialog coming from our post) but it does provide a reasonable way to achieve something close to universal access for rich web experiences, all with a unified code base and manageable testing requirements. Hopefully, the web community can all help us refine this idea and reach the common goal of providing true accessibility to all without an unmanageable mountain of code.

do not like at all

you’re going to end up having to write and support 2 or maybe even 3 versions of your css and you’ll end up getting all paranoid about things like “oh my site doesn’t look correct for people using IE4 from a cell phone, must now spend 10 hours correcting”.

far better solution is to use a solid css framework or templates and basically disregard any browsers incapable of handling such basic standards.

Also, please take a look at the tests that occur and the resulting matrix of browsers that pass or fail. Chris’s mention of the box model test is only a portion of what takes place. We have made this division of experiences without the use of sniffing, but rather by testing for features and handling. Please note that ‘failing’ the test simply means a different, yet still functional, experience.

Simply sniffing may not tell us what we want to know. We don’t care who you are (device-wise), we just want to know which level of experience suits you best. Even A-grade browsers can be turned into B-grade browsers by changing preferences around.

We think the technique has merit and we’d love some help to make it even better. Also please check out the comments on John Resig’s article as well, as many of these issues have been discussed there already.

Thanks!

Seems to me that in a non-trivial app, you could end up with a combinatorial explosion of these tests, ballooning the app size and startup time. Consider the awesome variety of ways that the spectrum of browsers fail on standards support, not just box model, but AcidTest du jour times browser type times browser version.

And then there’s failures that are hard or impossible to detect, like rendering errors, pathological performance gotchas, and strange memory leaks, not to mention mobile browsers where events don’t work like you expect (hello iPhone and mouse events)

The thing is, these tests run each and every time someone visits the page, whereas you could run these tests across a large sample of the browser space, save the results to a browser sniffing database, and then evaluate everything at compile time.

If you fail to recognize a browser when sniffing, either a) fall back to the tests or b) punt. The likely case is, you’ll still be serving 99.9% of the market until its fixed.

At the least, use a cookie to remember that the tests have been run and what the results are, so you can select a code base preoptimized for those results

I just don’t like the idea of having to pay for these tests *every time*. It generates suboptimal code runtime performance, size, and excessive network traffic, and lets you deal with a tiny percentage of the browser market that won’t be cause by sniffing.

One thing to consider though, is that user-agents capabilities change over time, so you’re going to be constantly evaluating what “enhanced” really means for your site.

Relying on javascript to ensure sexy rendering, might also be a barrier for some, and might not be considered defensive.

I’ve already adopted Chris’ technique of adding a classname to the body element, when javascript is enabled, which allows me greater control in styling my content for javascript-disabled browsers.