We’re all smitten with CSS3. It’s reinvigorated that sense of newness that CSS and Web Standards brought our way just a few years ago. We’re able to more easily replicate the set of design standards that has become nearly universal much faster than before with just a few CSS declarations. There are a number of CSS3 rules I’d be writing for every project, but I’m just not sure it’s as ready for prime time as many designers are making it out to be.

I’m having an honest-to-goodness back and forth with myself on this issue because I sympathize with two opposing sides to the same issue. I’ve thought about it so much that I’m not sure it’s as much of an issue I’m making it out to be, but would definitely love to have a targeted conversation about it.

I’d like to review the four rules I’d more than love to use without a second thought on every project I work on for the rest of my life, and explain the issues I’ve come up with (so far) regarding each.

Before (and after) I get to the list, however, I’d like to make my stance on CSS3 clear. I love the fact that it directly helps us as designers make a project go that much more smoothly. It helps us reduce the time we take to engineer the front end, allowing us to spend more time designing. I understand that if people are not able to, or choose not to upgrade their browser, it’s something they’ll have to deal with as the Web continues to mature and grow. It makes perfect sense that the faster we all adopt these “bleeding edge” technologies, it puts that much more pressure on the browser makers to implement things properly.

There’s an element of realism, however, that I feel sometimes takes a back seat to the wonderful things CSS3 (and HTML5) are currently offering us.

Border radius
By far the most popular design treatment you’ll find on the Web is rounded corners. I’d be willing to bet that there are more (completely different) ways to achieve rounded corners on the Web than any other design treatment, if such a statistic existed. The creativeness that has gone into the dozens of ways to best round the corners of a div blows my mind. The point here, though, is that it shouldn’t be such a pain to accomplish. With such a popular and generally accepted design treatment, there should be an easier way. Many designers have taken comfort (and a sigh of relief) through border-radius.

As a quick review, border-radius will automatically provide rounded corners on the referenced element. You have independent control over each corner, giving you a wide range of possibilities when adjusting your borders.

Being able to round the corners of a design element using a quick CSS3 rule is inspirational as it stands on it’s own. Combine that with my arguably favorite ability for border-radius to easily round the corners of images as well as elements with background-images and I’m head over heels.

Taking a step back and examining it, I don’t see a tremendously huge problem with using border-radius today on a production website. I’m not able to take advantage of it on client work, however, because no matter how hard I try to convince a client that visitors with less capable browsers won’t know any different, they’re still going to see a less elegant design. And that’s something I completely agree with.

I am not yet comfortable with putting a client site out there that degrades to the point, although completely accessible and usable, it looks unfinished and utilitarian.

Text shadow
The rise of OS X Leopard brought us the wildly popular text inlay effect achieved through a clever drop-shadow treatment to text. Tons of tutorials cropped up rather quickly with instructions to replicate the effect, and it’s something we see fairly consistently in new designs from both big names and small. We can all understand why, it’s a nice looking, elegant treatment that can improve things both aesthetically as well as improve readability when used properly.

Moreover, text-shadow can help on many levels when it comes to readability, and that’s one of the major reasons I’d like to start using it consistently today. It’s something that can be implemented on a very subtle level, and at the same time return some really excellent results without many people noticing.

Truth be told, unless the absence of text-shadow will morph type into something more difficult to read, I think using it is just fine on a client production site.

Multiple background images
If there are any two opportunities CSS3 brings that I would most like to use, it’s border-radius and multiple background images. I can’t begin to fathom the number of divs I could have saved over the past year alone.

CSS3 gives us the ability to layer multiple background images on a single element which can build upon any existing background properties. It’s useful on so many levels, I can’t begin to explain how excited I’ll be when it becomes standard practice to use.

Unfortunately, this is a property I only use on a select few personal projects simply because the degraded result produced is far too different to deem acceptable in my opinion. That is of course unless you’re simply adding just another layer of very subtle refinement. While some intentional results can be put in place with a clever combination of cascading background properties, in my opinion (at this stage) your time is better spent accomplishing your goal the “old fashioned” way.

Pseudo selectors
Pseudo selectors rock. It’s great that they’re so old, many have been implemented in modern browsers, but you can’t become too comfortable with them quite yet. Of anything CSS3 has to offer, pseudo selectors are something I use on nearly every project.

When it comes to pseudo-selectors, I still think of them as a method of progressive enhancement. The way I use them, the selectors provide that extra level of detail to a design that brings it to the next level. Using that approach, I think using pseudo-selectors is absolutely acceptable, and I’d even go so far as to fully recommend that they be used to tighten up the front end on any project. The changes they provide will definitely not be missed by viewers with non-supporting browsers unless you’re so aggressive with implementation, the render is drastically altered by their absence.

While I do tend to use pseudo-selectors, I find myself only relying on a few for the fine details I’m looking to apply.

When it comes to clients
Again, just to reiterate my stance here; these observations should be taken with a grain of salt. I’m only looking at the big picture, not taking into account the nearly endless variables and circumstances that come with every project that graces our monitors.

The biggest hill to climb by far, in my opinion, is getting the blessing of your client to go ahead with this more aggressive approach. After all, we were hired to produce a certain caliber of work. Unless your client is extremely Web savvy, and is somehow opinionated on the topic of how limited we are when it comes to CSS, their main concern will be that the investment they’re making with you will reach the widest audience possible.

The latest argument to skirt this issue is to simply present your comps after you’ve already began front end development. That is to say, some designers feel that presentation of a static comp is no longer applicable directly as a result of wanting to use progressive features such as CSS3. The idea behind it is this: if your client is using a substandard browser, the production site will look exactly like the approved comps simply because they’re using the same underpowered browser the whole time. Meanwhile, visitors with modern browsers will be graced with the much more pleasant version. As the client upgrades their browser, they’ll be elated that this new browser made their website look that much better! Although I’ve never tried that approach, I can’t quite stand behind it.

In my experience, clients are extremely detail oriented. They’re going to ask for more should they see the design in IE6, even if you took the time to beautifully degrade. At that point you have two choices; you can revert to the old school, or you can trek down the path of explaining CSS3 and why they need to trust you on this one. All the while eating those hours.

As I mentioned, this is something I’ve been going back and forth with for some time now, and I think having a conversation on the subject using realistic circumstances and case studies would be superb. What’s your stance on the issue, specifically when dealing with clients and not your personal projects? Do you think CSS3 is simply ready for prime time given the many repercussions involved? At what point will it be acceptable to implement CSS3 and not have to focus on fallbacks and graceful degradation?

from Monday by Noon