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.
When reading the term progressive enhancement, JavaScript is usually the first word to come to mind. It’s important to know that the idea of progressive enhancement is in no way limited to JavaScript, and can be applied to your documents in a number of ways. I just finished reading the latest post from John Resig, Progressive CSS Enhancement, which featured an innovative idea that hadn’t crossed my mind before.
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 classes, 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.
Testing rendering engines with JavaScript
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?
Comments
I like the idea of adding .enhanced to the body, IF the browser passes. However, there are few cases where I find I might even need to do this (one is hiding an element with Javascript only, which produces an unhidden flash after the CSS loads – there’s probably a fix but I couldn’t find one when I needed it!). Another (off the top of my head) might be to load rounded corner JQuery code for Opera and IE.
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 […]