They look good, particularly the grouped buttons. The shadows from the neighboring grouped buttons are a nice touch.
I think it might look a little bit better if the noise pattern didn't disappear on the buttons' down states. The noise pattern is essentially simulating a rough surface, so it seems a little odd that pressing a button would cause its material to change.
Try zooming into the play button in iTunes. It's a good example of a button with noise, even in the down state.
Too bad they don't follow platform conventions like normal buttons. On Windows, clicking a button and then moving the mouse off it while keeping the button down releases the button the moment the cursor leaves the button's area and the button isn't activated.
> As you may have expected, no images used here. Instead, an base64 string is used to create the patterned effect.
A base64 encoded image is still an image. Just from a syntactic point of view it pisses me off that people say this, it makes their accomplishment seem more interesting than it actually is.
But don't completely disparage it. It saves an HTTP request to include it in the CSS. (Though typically it compresses 30% worse. For smaller images like this, that is not an issue.)
Yeah I was just about to lay down the same comment - this is just stupid. If I wrote an article called "all css images!" and it was just a base64 encoded image, would that get even a single upvote?
The repeating pattern applied to the button isn't a stylistic pattern but a texture. Looks great none-the-less, I just wouldn't call them "patterned buttons".
Instead of classes for each color (".red", ".blue", etc) you should use classes which indicate state or function (".primary", ".warning", ".success"). Otherwise you might find yourself editing a lot of code just to change the colors of your buttons.
As I see it, classes named after colors are based on unstable assumptions about presentation. When these assumptions change, you've saved yourself a headache if all you need to change is one line of CSS, instead of every instance of, say, class='button color green' in your markup.
The advantages of pure CSS buttons are way over-hyped at the moment. After spending about half a day experimenting recently, our conclusion was that we’re going to stick with images, and just produce a hi-dpi and lo-dpi version to maintain quality on the new hi-res displays.
If you want a carbon copy of everyone else’s buttons, with a thin border, slightly rounded corners, and a gradient/inset shadow creating a slight rounding effect, CSS is OK.
However, as soon as you want anything more distinctive, you run into cross-browser problems almost immediately. IE9 doesn’t support CSS text-shadow and gradients. IE8 and below don’t support rounded corners or shadows either, and they seem to have problems using the full range of weights available with some popular web fonts, too.
Even with a bleeding edge version of Chrome or Firefox, there are only so many effects you can generate with styles alone, and even then the results of fine-tuned visual effects generated by Photoshop are often visibly superior to a limited version of the same effects applied using CSS.
In other words, there is still no browser available today whose rendering engine can compete with one of the heavyweight professional graphics applications. That’s hardly surprising, yet if you read all the trendy design blogs you’d think it was crazy talk! :-)
The thing that really swung it for us, though, was that most of the advantages of using only HTML and CSS turned out to be illusory anyway, at least for our site.
We do have to create a separate button for each label we want to use instead of just changing the text in HTML, but that takes only a few seconds with Photoshop. As I noted above, we spent half a day experimenting with button styles using CSS and never found anything satisfactory across the full range of browsers we have to support.
Having plain text in the HTML might seem better semantically, but it’s unlikely that we actually care about button labels for SEO purposes, and we still have all the same image accessibility hints available as we always did.
The image file size and number of requests might be important concerns in some applications, but if you’ve only got a couple of buttons on a page, it’s unlikely to make any perceptible difference to performance. They might even be smaller than trying to encode all the cross-browser styling information in CSS and/or adding various non-semantic mark-up in the HTML to support it, and that potentially applies whether you download them as separate images or you embed them in the CSS using the data: syntax.
In short, pure CSS buttons seem to have few actual advantages over images and tend to bring a significant loss of quality and distinctiveness in the best browsers and horrible degradation in older but still relevant versions of IE. Unless you actually need to generate the button labels on the fly — and even then, you can still use a background image — I don’t see a good case for moving away from tried-and-tested image-based buttons to a pure CSS approach for most projects.
there are only so many effects you can generate with styles alone,
and even then the results of fine-tuned visual effects
generated by Photoshop are often visibly superior to a
limited version of the same effects applied using CSS.
I can relate there, but for me, on the whole, it seems easier to declare and manage the rules for style, size, etc. in CSS rather than in Photoshop, where the analogue feels baroque (aligning elements proportionally without numerous guides? clicking through layer styles...).
I hope there's a more programmatic interface/extension to Photoshop that I've been missing.
There are certainly tools that Photoshop could provide but currently doesn’t that would be helpful for this kind of work. Then again, maybe the problem is that many of us default to Photoshop because it’s familiar, when Fireworks might be a better tool for the job; I know I’m guilty of that.
I think you’ve inadvertently hit on another advantage of using a graphics package to create buttons, though: you can optically align the button text so it appears centred and evenly spaced with a quick nudge, where a purely mechanical placement might be mathematically correct but look slightly off to the human eye.
21 comments
[ 4.7 ms ] story [ 56.4 ms ] threadI think it might look a little bit better if the noise pattern didn't disappear on the buttons' down states. The noise pattern is essentially simulating a rough surface, so it seems a little odd that pressing a button would cause its material to change.
Try zooming into the play button in iTunes. It's a good example of a button with noise, even in the down state.
I'd also wager 99.9% of users do not care in the slightest about that behaviour.
A base64 encoded image is still an image. Just from a syntactic point of view it pisses me off that people say this, it makes their accomplishment seem more interesting than it actually is.
The JavaScript code to generate a noise pattern is often smaller than the inlined base64'ed content.
As I see it, classes named after colors are based on unstable assumptions about presentation. When these assumptions change, you've saved yourself a headache if all you need to change is one line of CSS, instead of every instance of, say, class='button color green' in your markup.
I haven't had time to update the app in a while, but it's still quite handy. Also works well for (very) small icons.
If you had used an image, that would have been 4.17kb for the image and only 6.75kb for the CSS, for a total of 10.92kb (instead of 75!)
If you want a carbon copy of everyone else’s buttons, with a thin border, slightly rounded corners, and a gradient/inset shadow creating a slight rounding effect, CSS is OK.
However, as soon as you want anything more distinctive, you run into cross-browser problems almost immediately. IE9 doesn’t support CSS text-shadow and gradients. IE8 and below don’t support rounded corners or shadows either, and they seem to have problems using the full range of weights available with some popular web fonts, too.
Even with a bleeding edge version of Chrome or Firefox, there are only so many effects you can generate with styles alone, and even then the results of fine-tuned visual effects generated by Photoshop are often visibly superior to a limited version of the same effects applied using CSS.
In other words, there is still no browser available today whose rendering engine can compete with one of the heavyweight professional graphics applications. That’s hardly surprising, yet if you read all the trendy design blogs you’d think it was crazy talk! :-)
The thing that really swung it for us, though, was that most of the advantages of using only HTML and CSS turned out to be illusory anyway, at least for our site.
We do have to create a separate button for each label we want to use instead of just changing the text in HTML, but that takes only a few seconds with Photoshop. As I noted above, we spent half a day experimenting with button styles using CSS and never found anything satisfactory across the full range of browsers we have to support.
Having plain text in the HTML might seem better semantically, but it’s unlikely that we actually care about button labels for SEO purposes, and we still have all the same image accessibility hints available as we always did.
The image file size and number of requests might be important concerns in some applications, but if you’ve only got a couple of buttons on a page, it’s unlikely to make any perceptible difference to performance. They might even be smaller than trying to encode all the cross-browser styling information in CSS and/or adding various non-semantic mark-up in the HTML to support it, and that potentially applies whether you download them as separate images or you embed them in the CSS using the data: syntax.
In short, pure CSS buttons seem to have few actual advantages over images and tend to bring a significant loss of quality and distinctiveness in the best browsers and horrible degradation in older but still relevant versions of IE. Unless you actually need to generate the button labels on the fly — and even then, you can still use a background image — I don’t see a good case for moving away from tried-and-tested image-based buttons to a pure CSS approach for most projects.
I hope there's a more programmatic interface/extension to Photoshop that I've been missing.
I think you’ve inadvertently hit on another advantage of using a graphics package to create buttons, though: you can optically align the button text so it appears centred and evenly spaced with a quick nudge, where a purely mechanical placement might be mathematically correct but look slightly off to the human eye.