A few months ago, I did a post about CSS3, and I was not sold on it at the time. I agreed that the possibilities it presented were useful, but the browser support was lagging too far behind to begin using it. We live on the web, and times change quickly, and I’ve changed my opinion. I’m flexible, I want to grow and adapt and do what makes the most sense.
The driving reason for my argument is progressive enhancement. I do not believe all web pages should look exactly the same in all browsers, and I understand this is a huge shift in thinking. As an industry, we have wasted too many web development hours tweaking this, positioning that, and nudging the other thing to get everything to look the same across all browsers. I say wasted because the time spent on these tweaks did very little to substantially improve the user experience. I know, I know, the sizzle sells the steak, but plenty of research and data supports the notion that usability is of paramount importance to the end user. If you disagree, I challenge you to find 3 good looking aspects of Amazon.com, or eBay, or even Google.com. They’re not gorgeous, they work.
Back to progressive enhancement. Taking the time to make give capable browsers proper treatment serves (at least) two purposes. First, it gets us acquainted with the new features. The only way to improve at anything is to keep practicing it. The more we can master now, the more prepared we will be for using these techniques “in the big leagues” (with more, or potentially all people actually seeing them.) We do not have to know everything the moment a switch is flipped and a whole new world of possibility opens, we can explore and experiment in that world now.
The second reason it makes sense to use progressive enhancement is that it really doesn’t take that much longer to do. With lots of help from CTRL+C and CTRL+V, inserting three lines of code for border-radius, -moz-border-radius, and -webkit-border-radius does not take any longer than cutting up images with rounded corners, or inserting your favorite JavaScript technique to achieve that effect. The speed (as in the time to serve the web page) is greatly improved using the new techniques available. I’m always shocked at how peeved I can get by doing something that takes a few extra seconds ONE TIME as I lose sight of how many times that piece of code will load. Can I really be mad at something taking a few minutes if it’s going to be loaded in a browser thousands of times?
OK, there is one more key issue to discuss. If we’re using progressive enhancements, it doesn’t make sense to show clients graphical comps or mock-ups (psd’s, jpg’s, etc.) This practice has been the root of the “it-looks-different-on-my-machine dilemma” for years. Clients always want changes after the page is coded. Time is wasted making web pages look like pictures when they are actually completely different animals. And going straight to a prototype of a working page gives us the chance to show off more interactivity magic up front. Comps still have a purpose, we need something to drive our CSS/HTML, but the client does not need to see them.
Pay close attention here – it is critically important to be cognisant of usability when using new techniques. For example, if using a new selector makes one browser look pretty, but makes the text illegible in another browser not supporting the feature, evil has been done. The key is progressive enhancement, not utter destruction in some browsers.
What say you? Leave your comments!
