In my opinion, progressive enhancement is by far one of the most important things to embrace as a Web developer. Browser inconsistencies are a thorn in the sides of anyone making websites, but at the end of the day, visitors don’t care about the trouble you had making sure the design rendered well in all cases. It’s our job to ensure transparency in as many cases as possible.
Progressive Enhancement and CSS
I’ve written about applying progressive enhancement to your CSS in the past, but John’s article goes above and beyond my idea. To summarize the idea behind my piece written some time ago, I’ll provide a quick synopsis. The general idea was to simply script the DOM to include an external stylesheet which provided
ids, and other selectors which are only necessary should the reader have a fully capable browser. These style sheets not only included some extra
classes etc., they included some value overrides on existing properties to help out with the behavioral aspect of the document. At the end of the day, applicable CSS would only be included should the browser be capable of effectively manipulating the DOM.
John’s article outlines a much more detailed implementation of progressive enhancement of CSS based on actual tests of rendering behavior. I think it’s a fantastic idea and it’s one of those articles that lead me to sit back and wonder why I hadn’t thought of it. It also had me thinking back on past projects, wondering where I could have applied a technique such as this to make my life a bit easier. I think running some tests using the method outlined by John could have saved me some work by providing a (gracefully) degraded experience to a reader running IE6 (let’s not kid anyone by referring to sub-par browsers in general).
What do you think?
If you’ve had a chance to read John’s article, how do you feel about it? Do you think it blurs the line between document style and document behavior? Can you see yourself using some of these tests to help you create better websites? Do you think it puts too big a burden on the developer? Or is that burden something we’re forced to accept as a way of life?
Also, since I now ignore IE5 (or add ‘upgrade your browser’ in a conditional comment), so the comparison tables at http://www.filamentgroup.com/lab/delivering_the_right_experience_to_the_right_device/ seem excessive. For instance IE for Mac OS X is no longer in development and can effectively be forgotten, as can older versions of browsers, since the auto-update ensures that most users are reasonably up-to-date. Perhaps a usable table (and ‘testUserDevice.js’ script) could be adjusted to filter out browsers with (say) < 1% usage.
In short, I find these kinds of things *too* diligent. I'd documentation and usage to be lighter, and have a backwards compatibility cutoff point. Perhaps have a JQuery-like customisable 'set of features' – in this case browser tests – before downloading the script. Nowadays, I *never* want to test for IE 5.
[…] Revisiting Progressive Enhancement in CSS – Jonathan Christopher […]