
Make CSS3 buttons that are extremely fancy - ssclafani
http://technology.posterous.com/make-css3-buttons-that-are-extremely-fancy
======
coderdude
How hard is it to upload a demo page? I can't stand CSS tutorials with
screenshots or images as a demo.

~~~
jjcm
<http://jjcm.org/css3-buttons/> Here's a demo page. I agree though, ridiculous
that it didn't include one.

 _edit_ \- tried them in IE6/7, they don't degrade that gracefully. They exist
and work fine as buttons, but visually it's hard to tell that they are. If you
use this I'd recommend adding a :hover on the span's background color as well
just so a user knows to click the thing.

------
Griever
These are nice, but I still find that Zurb's example's are still the best out
there.

[http://www.zurb.com/article/266/super-awesome-buttons-
with-c...](http://www.zurb.com/article/266/super-awesome-buttons-with-
css3-and-rgba)

I use them on nearly all of my projects.

~~~
bemaniac
The main difference is that these buttons require _no_ images, while the Zurb
ones still require an image. The lack of images makes the buttons highly
scalable.

~~~
charliepark
On Github there's a version of the Zerb buttons that's pure CSS. I haven't
tried it in IE, but it looks good on Safari and Firefox:
<http://github.com/gr2m/awesome-buttons>.

------
bradgessler
For those SaSS fans out there checkout compass's CSS3 gradient helpers
([http://compass-
style.org/docs/reference/compass/css3/gradien...](http://compass-
style.org/docs/reference/compass/css3/gradient/)). Compass does not include
the dx filters, but that would be an excellent thing for that lib to support.

Also, the markup Posterous uses is more verbose than it needs to be. We
figured out a way use plain 'ol <button/> or <a/> tags and style them as
buttons. Maybe I'll blog about that when we roll this stuff out.

Visually, those buttons look good.

~~~
Eugene3v
This looks very cool, however it doesn't seem to work in IE... :(

------
seanalltogether
Something about the corners of the button are really bugging me.

~~~
jws
Concur. Those lower corners have serifs on the first two and gaps on the
third.

~~~
norova
In a live demo of the buttons in Chrome those irregularities are not present.
I think it might be a Safari thing? Either that or JPEG compression artifacts.

------
DenisM
Another great button tutorial:

<http://news.ycombinator.com/item?id=1255023>

------
amadiver
It's kinda strange to me that CSS devs (designers? devigners?) would violate
DRY in such an egregious way every time they want to create a gradient:

    
    
        background: -webkit-gradient(linear, left top, left bottom, from(rgba(220,220,220,0.6)), color-stop(0.5, rgba(100,100,100,0.2)), color-stop(0.5, rgba(0,0,0,0.21)), to(rgba(0, 0, 0, 0.20))); 
        background: -moz-linear-gradient(top, rgba(220,220,220,0.6), rgba(100,100,100,0.2) 50%, rgba(0,0,0,0.21) 50%, rgba(0, 0, 0, 0.20));
        filter: progid:DXImageTransform.Microsoft.gradient(GradientType=0,startColorstr='#99dcdcdc', endColorstr='#33000000'); 
    

I don't work with CSS extensively; is there a better way?

------
josefresco
I love how the author includes a line within the article that pretty much sums
up the insanity of using pure CSS to create buttons ... "a small truckload of
CSS" A designer could replace that truckload of CSS with 1 image and 1 line of
code.

We gotta stop sometimes and think .. what are we trying to achieve exactly?
Strikes me almost as an extreme diet that excludes 100% of fat from your
intake just for the sake of having no fat irregardless if it's healthy or
causes you to lose weight.

But in the "cool project" nerdy line of thinking .. it's pretty neat.

~~~
ugh
Three images, actually (normal, hover and active). Six if you have buttons in
two different colors. Twelve if you need the buttons in two different sizes.

You need a truckload of CSS to define how a button looks but you only need to
do it once. Creating arbitrarily colored and sized buttons is as easy as
adding one or two lines of CSS. And at some point in the future we will
actually be able to drop the prefixes and the CSS will become quite elegant
and compact.

~~~
rimantas
Well, you can still do it with one image (CSS sprites and kind of "sliding
doors" technique), however an image is one more resource to maintain, and that
"truckload" of CSS in reality is smaller than HTTP request headers of an
addtional request for said image (even if responese is 304 Not Modified).
Sure, you can properly set Expires into far future and save request for
repeated visitors, but then you will need to come with a versioning scheme.
All in all, CSS way is simpler and easier to maintain. Add some more bling
with CSS transforms, e.g. some nifty color fade/shift on hover and it gets
realy tough for an image based solution to stand a chance.

~~~
ugh
All valid points, I looked at it more from the maintainability point of view,
not so much the speed angle. You will have to maintain a Photoshop file, have
some mechanism in place to stitch together your sprites and export a truckload
of different images. All that can be automated up to a point, but still. Seems
like a lot of hassle.

------
pornel
I'm proud of such button I've implemented on <http://imageoptim.pornel.net/>

Here's unminified CSS: <http://pastie.org/1097542>

------
wmeredith
This is a great article, thanks for sharing.

------
metamemetics
> _Made with pure CSS3_

False. Webkit extensions, mozilla extensions, and internet explorer extensions
are NOT pure CSS3. They are ugly browser hacks. This is hard-coded to only
work on the Big 3 and will never work on Opera, thanks for not supporting
browser freedom.

~~~
ubernostrum
These are vendor-prefixed implementations of features which are present in the
current drafts of future editions of the relevant standards. As such, they are
neither an "ugly browser hack" nor an attack on "freedom"; in fact, _this is
the way it's supposed to happen_. Once the standards go final and the browsers
get compliant implementations, the vendor prefixes will go away.

So... how about you get that big chip off your shoulder and let people get on
with their work?

~~~
metamemetics
Author:

> _To achieve these effects, I needed a small truckload of CSS_

You:

> _Once the standards go final and the browsers get compliant implementations,
> the vendor prefixes will go away._

So the implementation is excessively long, temporary, and to be changed to
something more standards compliant at a later date. Seems like the definition
of "ugly hack" to me.

And I'm not talking about supporting an outdated browser like IE6 here. I'm
talking about a browser whose _public_ releases support more "pure CSS3" than
both Gecko and WebKit.

~~~
ubernostrum
_So the implementation is excessively long, temporary, and to be changed to
something more standards compliant at a later date. Seems like the definition
of "ugly hack" to me._

The idea is that until the standard goes final and the implementation has been
checked against it, _you can't know_ that the implementation is correct or
even that the syntax for the feature will be the same in the final version. So
rather than yank the rug out from under people later on, you use a vendor
prefix until the standard is finalized and the implementation's checked out.
Then people can drop the vendor prefix.

 _I'm talking about a browser whose public releases support more "pure CSS3"
than both Gecko and WebKit._

And... well, Opera's doing it wrong. CSS3 is not finalized. CSS3 may go final
with subtle or even significant differences from the current spec. And then
anyone who relied on Opera's implementation and patted themselves on the back
for being so ahead of the game will instead be up a creek.

~~~
metamemetics
My implication was to do something standards compliant and browser-neutral
like 1px wide PNGs and (for the super fancy) JavaScript. Avoid non-standard
CSS hacks entirely. It has a higher chance of breaking and not-working
because, as you said, CSS3 is not finalized.

I wouldn't care if it was supposed to be some sort of academic tech-demo, but
in the comments the author says: > _On Posterous they are going to be used in
many places_

edit: moral: JavaScript enabled\disabled is 1 axis of degradation. Non-
standard CSS3 hacks have 3 axises: Browser type, browser version, state of
CSS3 spec. It's a statistically worse bet.

~~~
coderdude
Do you actually develop sites with this kind of thinking? I'm shocked that
you'd rather use a 1px png (adding an additional http request) and JavaScript
to achieve an effect that CSS can handle all on its own. We use browser
extensions because specs like CSS3 aren't suddenly turned on one day like a
light switch.

You can make your layout look nicer on cutting-edge browsers and by the time
the old browsers are no longer around and the spec is in widespread use you
can remove the extensions. It's trivial to remove CSS from a stylesheet. It's
usually a pain in the ass to re-implement CSS functionality from 1px pngs and
JavaScript hacks once all the browsers have caught up.

~~~
metamemetics
> _CSS can handle all on its own_

CSS can't handle it all on its own is the point. And yes I'd rather incur the
extra bandwidth of a 1px wide crushed PNG in order to have simpler code and
have my site support all-browsers, including ones whose team made good CSS a
priority before other browsers did. Rewarding the large monoliths by coding
specifically for them simply because of their popularity while punishing teams
that _actually_ prioritized CSS is what got us into this mess in the first
place. Would you encourage this behavior pre-CSS4? pre-CSS5?

