Konqueror (and other khtml browsers?) support border-radius as well, not sure about the other styles.

-khtml-border-radius: .7em;

John, you are not the only one promoting CSS3 shiny buttons. Except I am evil and used a couple of superfluous divs for visual effects.

I also learned something new today with -webkit-gradient, thank you.

Firefox 3.1 supports -moz-box-shadow

Bug in Chrome makes using border-radius and box-shadow together a bad idea

The button element is not supported by some mobile browsers at the moment (IE on WM6 for example) so I don’t like to use it. Could use input type=“submit” except Safari on a Mac does not want anybody else to control the look and feel right down to the text size. ( page 7 of 2006 button presentation )

Expect extra shiny “buttons” from me, especially using -webkit-transition for special effects.

This is too funny. I just used the same CSS technique on a project, minus the shiny “web 2.0” background. I’ve experimented with all the same described properties except for the “css gradient”. I wasn’t even aware it existed, until now. I’ve always used a background image in my CSS, which I will probably still do in order to make the buttons look as close as possible in all the browsers. I can deal with the square corners instead of rounded when using the radius property, and so do my clients, surprisingly. Anywho, thanks for sharing the knowledge, John! Learned something new today.

-webkit-gradient ?

Now I feel like a fool! How come I missed that gem? ;)

Nice tutorial! I’ll probably use that in the future but one thing doesn’t half get my goat. That is; “Sites don’t need to look the same in every browser” I hate reading that, but not from a web designer’s perspective. (I understand the logic of the statement) From a client’s perspective it sounds like a cosmic sized cop-out.

Imagine buying The Dark Knight on DVD and watching it in all it’s glory on your 50” Sony LCD telly and then taking it over to your mates house, putting it on his 37” Samsung TV and seeing that the Joker is no longer Heath Ledger but someone who resembles Jeremy Kyle. The performance is the same but the character doesn’t have the same visual presence.

Imagine, then, going to the manufacturer and saying “The Joker is totally different on my mates TV compared to how he is on mine!” only to have them come back with “The film doesn’t need to look the same on all TVs”

Obviously the two media can’t be compared that way but to most clients, that’s exactly how it will come off. You could squirm and throw jargon at them or you could give them an image based button and stay on their christmas card list. I know which one I’d rather do.

Of course this only applies to client work. In the spirit of “impressing your friends” and pushing the boundaries of CSS then it’s all jolly good.

Merry Christmas to all at 24ways!

Dan

Having experimented with this method and other ways of making fancier buttons with text that can be edited, I have reluctantly returned to using image sprites, at least until browser support catches up a bit.

Filament Group have done some excellent work on this subject since the new year, combining sliding doors and sprites with a few browser compatibility tweaks to create a professional result.

Buttons with sliding doors and sprites

Great article. I’ve been doing buttons like this for a little while now and it’s much better than making rounded corner images or sliding door techniques… Thanks for tip on the webkit gradient property too.. I didn’t know it existed!

Very nice tutorial – its always good to see the new CSS3 techniques put to good use, though I do disagree to some extent with your comments about whether websites have to look the same in every browser.

Obviously, the answer is no they don’t and that makes perfect sense when you consider a website as a whole. With such a range of browsers out there, trade-off’s need to be made and assuming you are following a process of graceful degradation then there should be no problems.

However, when it comes to UI elements such as form controls, buttons, navigation etc. then I would argue that it is poor usability if they do not look and/or behave in a similar fashion across different browsers.

In the example, there is a massive visual difference between the rounded-corner-gradient button and what is displayed in the less-able (but often most used) browsers. For a user who is viewing the site on different machines, such as at work and at home, it is easy to see how confusion can result when suddenly a familiar element of the UI has changed. The user isn’t going to know or care about the technical reasons behind – they will get confused/frustrated as to what is going on.

Going beyond the usability concerns around having UI controls look and feel differently cross-browser, another consideration is around branding as a whole. Many companies I work with have a defined look and feel for things like buttons in their brand style-guides. This approach makes it very difficult to respect brand identity.

Again, I enjoyed the article and I hope I’m not coming across too negative, but I think the usability side of things is an important consideration when it comes to deciding on your website implementation and the degree of cross-browser variation you are prepared to accept.

If you were really crazy, you might look to use the Shadow filter in IE.

http://msdn.microsoft.com/en-us/library/ms533086(VS.85).aspx

(PS: the textile didn’t like the URL because it was trying to be “smart” with the closing parenthesis)

It looks nicer the firefox anyway that gradient is awful but I know that's not the point.

Thanks for the tutorial I hadn’t seen the gradient support utilised like that before.

Andrew

For a user who is viewing the site on different machines, such as at work and at home, it is easy to see how confusion can result when suddenly a familiar element of the UI has changed.

I think you have to credit users with a little more intelligence than that. The context of a UI control is way more important than how it looks. I really don’t believe a user is going to break down in a state of confusion because they were sure that button had rounded corners last time they looked.

Thanks for the great and eye-opening tutorial, John! This is also fuel for my talk at WDN… ;)

One thing, though: I’ve noticed that the button on the example page is unstyled and not the final version described. Viewing the source, it looks like the CSS is missing and the button has a class of “unstyled”. (Feel free to delete this paragraph once the page is fixed.)

One thing, though: I’ve noticed that the button on the example page is unstyled and not the final version described.

That button is showing how the initial HTML button looks with the browser’s default styling. So it’s ground-zero, not final version.

I also experimented with this using a single a element and no images, in my article about border-radius issues. Another tip: use rgba colors for shadows, they will look good on every background.

Here’s the test page.

John, great articled as always, my favourite so far.

I only recently started to experiment with these selectors but like a few posters, above me, I’d never even heard of the -webkit-gradient. Can’t wait to start trying that out.

For a user who is viewing the site on different machines, such as at work and at home, it is easy to see how confusion can result when suddenly a familiar element of the UI has changed.

Chris, but you are getting that now with Safari and input type=“submit”. Which is controlled right down to the text size.

The argument for is everybody using Safari knows that is a submit “button”. Argument against it is leaves no options for the website designer or user to style, not cross browser compatible, (use any other browser and the “button” looks very different) and limited options to resize by user.

@Dan: Fun, but I’m gonna have to disagree there Batman.

Heath Ledger is ‘content’, not presentation. Without Ledger, the meaning (ie: the performance) of Joker is totally different. The Dark Knight isn’t The Dark Knight without Ledger. That is not what “Sites don’t need to look the same in every browser” is about.

It’s perfectly fine for a movie to look different on different TVs — they do anyway. Colour saturation will be different, sound quality too. Maybe you get additional special features on a DVD by playing it on a more modern DVD player? That is OK too.

What wouldn’t be acceptable would be somehow excluding people from accessing the movie (even in black-and-white and with mono sound).

And don’t get me bloody started on the UK analogue TV switch-off ;)

From a client’s perspective it sounds like a cosmic sized cop-out.

I think it’s Tom Cartwright from the BBC who talks about ‘equivalence’ in user experience, no matter the capabilities of the user agent.

I think that’s a far healthier way to approach web design. It’s an illusion to think we have the capability of delivering the identical presentation to every user – it’s neither possible, nor desirable to do so. What’s important is that no user is ‘second class’ – the experience should be equivalent.

That’s not easy to achieve (for example, I think we’re some way off that for this site at the moment, in terms of visual quality in old browsers), but it’s a better target to be aiming for.

@ Malarkey – You’re right there, and that’s why I said you can’t really compare films and websites like that. The Batman comparison wasn’t how I see it personally but I maintain that clients could very well see it like that.

My comments were more a “Stupid unreasonable clients!” rant than a dig at the methods outlined in the post. It’s snazzy, thinking-outside-the-box CSS for sure but I still believe that it could cause you some client headaches when presented to the less understanding.

A plus point though, like Drew rightly said, is that it does squeeze some much needed value out of older browsers which is never a bad thing.

There’s a real, growing trend on using CSS3 techniques on live sites—and it’s fantastic to see it.

But great as webkit gradient is, I wonder if it isn’t far too early to try implementing it. I mean, you’re right, things don’t need to look exactly the same on all browsers, but by using this you’re only talking to a sliver of the entire market (i.e., Safari & Chrome). When you’re leaving out Firefox & Opera as well as the obvious drop-out, Internet Explorer, I think that the cleverness goes too far.

Adopting a strict ‘recycling’ policy on background images—say, using them in both your navigation & on buttons—means that you can cover more cases and still have your shiny Web 2.0 goodness :)

I like the sound of equivalent experience, and would love to read any of what Mr. Cartwright has said on that.

I wonder who’s deciding what is equivalent. Some users will view the presence of a button, regardless of rounded corners or even color, as equivalent. If a company’s designers value a certain visual design / feel highly, and a large number of their customers are using IE 6, they’re less likely to appreciate developers coming to them with ideas of progressive enhancement.

Is the idea of ‘progressive enhancement’ saying that designers shouldn’t care as much about the rounded corners on the button? That there are more important parts to care about when building a unique and beautiful experience on the website?

Are we saying that a designer that wants rounded corners in IE 6 is viewing it wrong, or at least that they need to be enlightened to designing for the web?

I like the sound of equivalent experience, and would love to read any of what Mr. Cartwright has said on that.

The best I can find is a recording of his @media 2008 presentation. It’s hard to follow without seeing what’s on the screen, but here it is

If a company’s designers value a certain visual design / feel highly, and a large number of their customers are using IE 6, they’re less likely to appreciate developers coming to them with ideas of progressive enhancement.

You’re confusing progressive enhancement with the ability to implement a given feature in a given browser. Of course you can have buttons with rounded corners in IE6, but it’s going to involve hacking around with images.

You may decide that the advantages of not relying on images is worth the trade off of not having those rounded corners in older browsers. If so, progressive enhancement enables you to provide those more visually appealing buttons for modern browsers, whilst giving older browsers still perfectly serviceable squared corners.

The squared and the rounded corners are equivalent. Everyone has the same content, functionality and care in their user experience. Just some people have corners one shape, and others another.

Not to be too cynical, but this seems like a lot of CSS for a technique that only works as fully intended on a browser with ~5% market share (depending of course on your visitor demographic).

The addition of one surrounding tag (such as a span) and the use of two images can create the same effect cross-browser.

The point about making things look the same in all browsers is of course one that can be discussed at length, but the subject matter of this article is applying a visual technique to an element on a web page in order to make it look pretty. If the technique only works for 5% of your visitors, then maybe it is not the most optimal technique to be using.

Swell post – bonus points for styling the button tag…some folks aren’t privy to its existence. :/

I just can’t wait for CSS3 to be widely adopted…it’ll make things so much easier and that much more fun.

Nice article John.

Oh, IMHO and as a front end developer, I completely agree. Web sites DO NOT need to look the same in all browsers.

I’ve been using border-radius (and the webkit/mozilla versions of the spec) in my interface work for sometime now. While I haven’t gone so far as to include shadows or gradients, I do make occasional use of text-shadow as well.

I’m a firm believer in graceful degradation, and if you’re careful in not over-exerting the design (layering up with gradients and shadows and all that hullaballou) you can end up with a relatively consistent style across browsers.

The example here has some very extreme variances, but that’s hardly going to be the case if you use these techniques with some forethought rather than a demonstration.

Drew, thanks for that link, I’ll give it a listen, and hope this photo is enough of a visual.

You’re confusing progressive enhancement with the ability to implement a given feature in a given browser.

I don’t think I am. I could have said that better. I was including the idea that a site need not look the same in all browsers in progressive enhancement. Though it’s not strictly part of progressive enhancement, but that notion is a reason the approach exists.

The squared and the rounded corners are equivalent. Everyone has the same content, functionality and care in their user experience. Just some people have corners one shape, and others another.

But where is that definition of equivalent coming from? Isn’t it one meaning among many? A particularly cautious designer may not see two buttons that look even slightly different as equivalent (or, may not agree that whatever Tom defines as equivalence is acceptable for their site).

And that’s where my question comes in. Because when we say that ‘web sites DO NOT need to look the same’, we are also saying that this designer is too cautious, picky, or even mistaken about the what comprises their organisation’s visual identity. Or, “No, the rounded edges on your buttons are not essential to your visual identity.”

Writing about progressive enhancement is not making such claims, and this question is veering away from the article.

OK, so I did a bit of experimentation on a recent commercial project and found that (in my experience only) people didn’t seem to notice that IE didn’t have rounded corners when the radius was 5px and below.

It’s how I got to use the delights of border-radius and ensure that I’m allowed to keep doing it :>

In my opinion this

-webkit-gradient(linear, left top, left bottom, from(#e9ede8), to(#ce401c),color-stop(0.4, #8c1b0b))

is getting remarkably close to this

<linearGradient id=“fadedown” x1=“0%” y1=“0%” x2=“0%” y2=“10%”>
<stop offset=“0%” stop-color=”#dad” stop-opacity=“1”/>
<stop offset=“100%” stop-color=”#ebe” stop-opacity=“1”/>
</linearGradient>

The first is CSS and the second SVG.

I’m a bit confused as to why we all want to be able to create scaleable graphics in our CSS when we can already do that in SVG. With an SVG background you can set the border, the border radius, a box shadow, a gradient as well as the background color. This means that lines 6 through 13 in this example could be one line:

background-image: url(button_back.svg);

Yes you need another 14 lines in an SVG file, but the possibilities are far greater than CSS3 will ever deliver.

Opera have seen the light and enabled SVG as a background in 9.5, I’m hoping the others will follow suit.

While it’s nice to see a showcase of features to come, I really don’t see this being a viable technique for any of my clients for 2 reasons. Primarily, it would difficult to convince a client that focusing design efforts on 6%-8% of users while excluding 70% is a good idea. As a designer, taking time to tweak gradients and shadows that won’t be seen by many users seems like a waste of time, especially considering an image version of the button could be thrown in via conditional comments to support other browsers. If your arguement is that the lack of rounded corners and gradients won’t hurt the user experience, why include them at all?

Additionally, this brings back memories of when I first got into web design. I was self taught and used a variety of IE specific filters. After learning about standards and being enlightened by many a fellow designer. I stopped using them and stuck with standards.

Now it seems that browser specific filters are fine, as long as they start with -webkit or -moz. It really seems like we’re getting into the same situation by creating vendor specific code. While the vendors maybe better, it doesn’t change the fact that this encourages browser specific rendering, which is what we’ve been fighting against for years.

I know that my opinion is hardly popular, but I’m just seeing the same things happening all over again.

Do websites have to look the same in different browsers? No, they don’t have to. Do people (read: clients) want them to look the same? Yes, they do.
And really I can’t blame them. A good webdesign consists entirely of a consistent style. Even the smallest details should integrate together as a whole. People who say websites do not need to look the same are in my view either lazy or frustrated with the current state of standard implementation. (both of which I can sympathize with).

I am also questioning the fact of using browser-specific “filters” and then override them with the genuine CSS3 property so the site is “future-proof”. How far into the future should we design? Does this mean I start designing completely css3 compliant and simply wait for the future to catch up with my sites?

These kind of articles provide us with a nice test-case and some fun. But should be seen purely from an educational point of view. They are not practicle. Sorry, just my opinion.

Nice Article. I think sometimes people miss the whole point of “progressive enhancement”. I have read some posts with people saying all the buttons have to look the same, and in some cases this is true. As a designer you have to use your “judgment and experience”. Obviously if it is the homepage of a website and a giant button that says “buy product” you might not use this technique. However, there are many smaller buttons throughout most websites whose “function” is far more important than “form” and for those buttons this approach would make perfect sense. If done right with good colors, type, etc., even the IE version could still look quite nice. These type of small additions are not mission critical and often times make very little if any difference to customers/clients. The bottom line is that it a good technique that can definitely be used at the discretion of a good designer.

Thanks to all who commented, and apologies for taking a couple of days to replying – which only makes it all the harder!

Some random responses.

Nick Cowie – I’m not seeing box shadow in the current beta of FFox 3.1 I’m using – fingers crossed it’ll be there, that would be even cooler.

To respond to those observations about the usefulness of these tehniques or otherwise in certain contexts, with particular clients, and so on, might I in particular point out that the tutorial was much more about demonstrating a number of techniques that will certainly be of increasing use down the track, than arguing that they should be used out of the box in all circumstances right now ;-)

However, I continue to be a very strong advocate for trying to articulate to clients that it is a commonly held but ultimately futile belief or goal to strive for cross browser conformity of appearance.

The irony of course is that users never know that a site looks different in different browsers! They almost invariably use a single browser, and see the site as rendered in that browser. This is something we almost always overlook in this debate.

And, ultimately, the same page will look different across platforms regardless of whatever effort you go to – even if you render out an image and simply have the entire page as that single image.
Indeed, if sites don’t look different on different browsers, that often causes users to complain. Safari on Windows uses a different form of front rendering than the platform’s cleartype (which of course can be turned on and off, or tweaked by the user anyway) and this has caused no small amount of complaint from Windows users.
Similarly, mobile optimized versions of sites obviously look different from the “standard” version, and yet, I expect within the next 12 months that the significant majority of heavily trafficked sites will have mobile optimized sites. Given the nature of current mobile traffic, I expect a great many sites to have iPhone optimized sites. And iPhone of course supports css gradients, border-radus, text and box shadow and so on!

If I were to argue a rule of thumb for choosing whether to adopt technologies like css gradients, border-radius, text-shadow and so on it would have nothing to do with browser conformity. It would be

will the site provide all of the information and functionality to users of all browsers, regardless of disabilities?
will the site look attractive, to the users of all browsers
will the site conform to users core platform expectations? (the shiny button example probably fails that test – but as mentioned, the goal was a demonstration of a technology)

The issue of CSS versus SVG, as I see it is this. There are orders of magnitude more CSS knowledgeable developers than SVG knowledgeable developers. Most browsers already have the capacity to display SVG, but by making some widely used aspects of SVG available via CSS syntax, the adoption of vector based browser native graphics will increase enormously. That will have the attendant benefit of making developers aware of the capability of SVG, and some of the core rendering concepts, and I’d predict increase adoption of SVG.

Thanks again to you all for your comments, and it is interesting to see how what I thought would be a fairly non-contentious exposition of some cool CSS tricks ended up sparking interesting philosophical discussions.

That rocks John, now hopefully it wont be too long before we’ll actually be able to apply it in widespread use.

I think you have to credit users with a little more intelligence than that. The context of a UI control is way more important than how it looks. I really don’t believe a user is going to break down in a state of confusion because they were sure that button had rounded corners last time they looked.

Credit users with intelligence? Now that’s a novel concept. ;)
While I agree that most users will have no problem coping with the difference – it still leaves a bad taste.

Users have little problems with unstyled buttons looking different across different Operating Systems because they
already know this phenomena from 100 other websites – and because such buttons at least blend in with the rest of the UI.

The story is different when you confront the user with a carefully styled button that looks “good” in one browser but “broken” (degraded) in another, where neither version resembles a standard style that the user knows.

The mental framework of our common, non-technical user has no concept for this scenario – his brain will raise an unconscious “something is wrong here”-flag when he encounters it.

Very sweet. I look forward to the day when, once again, images will be used for images and only images! Markup and styling will once again be all we need for text and links……..

Wicked, thanks for the tutorial, never knew you could customize buttons, i hate the preset button that come with forms. Will spread the shiny button love immediately!!!
Thanks, Matt.

Wonderful article – and great feedback in the thread. I know this is probably a “cobweb” post – but I want to interject to the “websites must look same in all browsers” issue.

I am a front end designer, back end developer and I wear many hats as an admin. My background is print publishing and advertising – having moved into web design/development in 1993.

Through all my years working on websites, I’ve watched as browsers from all over manage to mangle our code. Its given me no amount of grief working at getting my sites to work in browser a, b and c in the minimalist uniform way. As far back as 1993 I’ve lamented over work done for netscape (in present time – mozilla type browsers), only to watch as ie would get all warped. Yeh, though I walk through the valley of the shadow of microsoft….

CSS came to my rescue – and I’ve coded beautiful web spaces. I’ve become quite popular in gaming circles as a site designer – but in the professional world, still the demand is for sites that “…function and look the same all over…” – particularly for my international customers. That is the bane of any “professional” designer/developer with international clients – or even with localized clients.

EG: Designed ecommerce site for beautiful usability in FF3, only to have IE6 users (particularly the company president) complain that things are misaligned or even missing! How many work-arounds I can code in a day!

Overall – I have to agree with others in the comment thread about the twinge of emotion when I hear colleagues say that designs are EXPECTED to be different from browser to browser, platform to platform. If the SRD requires uniformity due to corporate demands, then by all mean… if we want to get paid, we better put out.

… or am I on a different planet than most….

terrific tutorial, and still very timely.

i had no idea you could get such customization and those types of button through css. i guess i can ditch my images!

thanks!

This is great! I’m always looking for simple explanations for things like this, as whenever possible, I’d much prefer to just code things in rather than have to get something designed as an image. Thanks very much John.