Content last updated Aug 17, 2011 – First impression of Firefox 6.
NOTE: I’m updating the ol’ blog to honor its 1,000,003-word birthday, and some pages require individual attention. This is one of those pages. Please pardon the mess.
border-radius seems to be a hot topic these days, what with CSS3 including it and some broswer vendors already implementing it. I just think it looks nice.
I originally created this table to see how the various browsers acted, but it’s also a very useful table of examples of how to use border-radius in your designs. Even after many readings, some of the wording in the proposed specification can be confusing. I’ve done my best to get things right here.
The top half of this table is looking pretty good these days, if you ignore the elephant in the room whose name will not be mentioned (until later). Eventually this page will be a syntax reference instead of a compliance table. That will be a Good Thing.
Safari and Chrome
Big news, everyone! Safari 5 is out and has caught up with Google Chrome. And with Safari 5.1 we finally have support for expressing the radii as percentages.
If you do not need to support older versions of Chrome or Safari (and Apple’s Software Update will make sure Safari 4 goes away very quickly), then the -webkit- prefix is a thing of the past!
Firefox 3
As of Firefox 3.6.3, it is still necessary to use the -moz- prefix. More importantly, the syntax for specifying individual corners is different for Mozilla. I tested to see if the latest might also accept the syntax from the spec, but it did not. For the time being I believe it’s better to use the shorthand to specify the different corners. That way your CSS markup will be the same as the standard except for the -moz- prefix.
Firefox 4 and 5 and… 6?
Firefox 6? Really? Are we suddenly in a rush to bigger version numbers? Anyway, no big change since Firefox 4. I’m going to add some new tests, but I won’t go back and fill in old browser versions. At first glance, at least, FF6 = FF5 = FF4.
The biggest news with Firefox 4 is the move to the standard CSS for specifying individual corners. Hooray! It will still accept the old -moz-wrong-order prefixes, but going forward Firefox will be playing well with others. Firefox worked out a couple of other kinks as well, and is looking pretty good overall.
Opera
Opera 10.5 has border-radius and it’s pretty complete. There are a couple of odd bugs that make me think they just need to look at this page and their programmer will slap his head and say “d’oh!” and all will be well in the next release. [Note: Opera 10.6 still has those bugs.]
Internet Explorer
Wow! Internet Explorer 9 beta has, as of this writing, the best border-radius support of any browser. It will be a good day when we don’t have to support Internet Explorer 8 anymore.
Other notes
I used SVG graphics to create most of the images for the specification column. That way I was able to type in the exact drawing commands based on my interpretation of the spec. The graphics are my own work and any errors are all my fault.
So here’s the table. I’ll try to remember to update this as new browser releases come out, but you can help too! If there are interesting cases that should be in the table, or if I’m slacking and browser support has changed, please drop me a note!
NOTE: I have been working on an implementation of border-radius here that addresses most (but not yet all) of the errors browsers encounter. It's a work in progress so it might be broken at any given moment, but it's not to shabby. I've made no effort to test this on various browsers.
Border is drawn in a way that does not match the proposed specification.
Border is drawn correctly but property name is different. Specifically, Mozilla specifies individual corners differently. Web designers should use the different syntax with the understanding that it will be obsolete later. Later rows in the table assume you understand that Mozilla is different.
Technically wrong, but not by much. Considering the things that the draft doesn't specify, the angle of the line between the colors seems pretty minor. The spec also "recommends" a gradient. NOTE: I am reviewing this right now; I suspect that Webkit is also subtly wrong. The spec uses English to describe a complex geometric relationship, rather than using math. There are several places they could have removed ambiguity and made compliance easier just by using numbers rather than words.
These two rows are exactly equivalent in terms of the CSS3 specification. I color-coded the values to indicate how the browser should expand the shorthand into the longhand.
The CSS3 draft merely says the transition between borders of different thicknesses be smooth, so although the Mozilla implementation does not match the illustration in the spec (it uses an elliptical curve on the interior where the illustration in the draft uses a circular curve), it is probably compliant. Web developers note that they cannot rely on inner borders looking exactly the same between fully-compliant browsers.
Note:
I recently updated my “Who the hell knows?” page. I added a section on how I think the standard should be for defining the transition between two styles at a curved corner. While I was at it, I corrected a couple of errors in the formulas as they were printed on the page. My interactive demo actually outperforms all current browsers for solid borders. The new section is really pretty slick!
Firefox 3 note
I should have tested with the latest Firefox 3 (3.6.12, I think) before chucking it off my computer. I’ll probably go back and test it at some point, or if anyone out there wants to check and give me an update, that would be great!
More on Webkit (Safari and Chrome)
The overhaul I said was necessary has happened. I don’t know if my test thingie helped them or not, but some very smart people went in and made things a lot better. Still waiting for dots, though…
Are you a Web developer looking for work in Cupertino? Contact me!
Copyright © 2009 Jerry Seeger
All Rights reserved until I get that creative commons thing figured out.
Boy, I tell you, being able to type the drawing instructions into an SVG graphic file sure made drawing the exact images a lot easier. Too bad I couldn’t use the .svg images in the page. *cough*InternetExplorer*cough*
btw, you can simply follow Mozilla’s changes on MDC:
https://developer.mozilla.org/en/CSS/-moz-border-radius
Contains also a complete browser compatibily table.
Firefox 4 recently changed the handling of percentage values (should ship with beta 6).
The final version will very likely have support for plain “border-radius” without prefix.
Pingback:
Pingback:
Very interesting.
By the way, in the 3rd and 4th row I think it should be:
top-left
while it is now:
top-right
Ameen
You are quire correct. I never was that good at left and right. (Don’t even ask about the alphabet.) I’ll fix that right now. Thanks!
thank you, very complete guide
Here’s one that’s always bugged me: http://www.flickr.com/photos/bobthecow/4046038689/
Interesting. I’ll look into that. Looks like a useful addition to the table. Tanks!
I wonder if my not setting a background color in the divs above has hidden other problems as well. I’ll have to experiment a bit. Thanks once again.
Updated to Firefox 3.5.4. No changes that I could detect; I checked for support of non-prefixed standard border-top-left-radius but no change there either.
Pingback:
What a great compat. table! It should be noted that Chrome 4b’s webkit (on Mac) get’s nearly everything right, except the 3 thick-thin tests towards the bottom.
Nice to hear the Webkit development stuff is getting closer to the mainstream.
Pingback:
Pingback:
Pingback:
Interesting overview, thanks!
One minor issue: your sidebar hides the table partly – can you reduce the width somehow?
If you look at the css for this page, you will see the class ‘fatass’. I tried to make the table skinnier, but I didn’t want line breaks in the code fragments, and I wanted the pictures to be big enough to be useful.
When I make my window thinner, though, the sidebar does not overlap the main table, and I’m surprised it did for you. What browser are you using?
Good overview, but the same thing happens for me in all my browsers:
– Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
– Google Chrome 3.0.195.33
– IE 8.0.6001.18821
– Safari 4.0.4 (531.21.10)
It’s affecting the table with id=”corner_table”
Thanks – it’s something to do with the preformatted setting I used for whitespace. I have no idea why the line breaks are not being respected on some browsers (all except the one I normally use). I’ll fiddle with it and get things working.
[Edit] to be specific, single line breaks were working, while two consecutive line breaks were ignored (Except in Safari for Mac). Everything should be fine now.
Pingback:
Pingback:
Opera has gone the plain border-radius way, as you can check in their latest builds available in http://my.opera.com/desktopteam/blog/
It’s still pre-alpha quality, but comes with lots of goodies http://my.opera.com/ODIN/blog/opera-10-5-pre-alpha-build-released-here-is-whats-new
Very exciting! Thanks!
You’ve commented in the blog that you won’t add this until it’s a stable release, but for any passers by reading this blog, all examples match the CSS3 Spec perfectly in Opera 10.5 except for /* radius less than border thickness */ and /* radius less than thicker edge */ which both look really bizarre in Opera.
Screenshot: http://files.myopera.com/lucideer/files/border-radius.png
They look somewhat similar to some effect you might expect to get using SVG paths actually…
I expect they are using their SVG library to draw the borders, and with just a little more tweaking they will have it all correct. Hooray Opera! If they do a really good job I won’t need to add a column to the table. No telling how long it will take them to get 10.5 even to beta, though.
I really should have thought of putting a link to a screen shot at least, and now you’ve saved me the trouble. Thanks!
WebKit has some pretty ugly hacks in their border-drawing code and eventually I think they are going to have to redo large parts of it. At that point I wouldn’t be surprised to see SVG in use there as well. Ellipses are much easier with SVG than with the ‘native’ WebKit path api.
Pingback:
Pingback:
Here’s some more issues with border-radius implementations not adhering to spec if anyone’s interested: http://frans.lowter.us/test/2010/border-radius/
Ooo, nice! I was thinking about investigating that stuff. If it’s all right with you, I’d like to borrow some of your effort to add clipping to this table, although your link shows it much better than the little cells of my table could.
I’m curious how content clipping works with dashed borders as well.
“If it’s all right with you”
Sorry, but I can’t take credit for finding the bugs linked above. That goes to Frenzie: http://my.opera.com/community/forums/topic.dml?id=374341
Nice work!
Altough I would also love to see percentage border-radii tested, e.g.:
border-radius:50%;
The above would effectively draw a circle (or ellipse, for that matter)
Also, maybe you could include Opera 10.5 (pre-alpha at the time writing) in the tests?
Thanks again!
Sure enough, percentages are in the spec. I’ll play with those; there are a couple of edge cases I’m curious about.
Opera 10.5 is discussed above (there’s a link to a screen shot in the comments), and by the time it reaches beta I’ll have to figure out how to make this table even wider – unless they do such a good job I can make the first column “the spec and Opera”. Here’s hoping…
Good call on the percentages. WebKit does not even have them implemented in the nightly builds yet.
Pingback:
[paraphrase]
I do not like the seagull, and I wish you would get rid of it.
[/paraphrase]
Edited by Jerry
The duck is far more appropriate in this place than your language, and is a reminder to myself not to take all this nonsense too seriously.
Since I’ve complained about the bird before, I just want you to know I’m not oily. ERrr, at least not the commenter oily. As for my hair/personality/investment strategy, Ha! THe color legend might be helpful if it came before the table. Since the table is so long, and it takes a while to get to explanation of why you colored stuff.
Pingback:
.border-radius is not supported by Internet Explorer.
Do you have any plans to update this page? I notice that there’s been much improvement, but some things still don’t work. Also, IE9 seems to have mastered border-radius.
I do keep the table up to date, but there are a couple of things missing right now – a column for Opera and one for the latest Chrome release. Google has been faster than Apple at getting webkit advances to the public (the green-outlined cells in the table work in Chrome). Opera 10.5 gets most things right. Firefox and Safari are up-to-date in the table, and IE9 is not worth bothering with yet.
The remaining issues in webkit (Chrome and Safari) will not be fixed until the border-drawing code is overhauled (borders are drawn with strokes, which makes tapering anything impossible, and clipping areas don’t line up properly with the edges of the borders). I was sorely tempted to dive in until I got a paying gig. Opera 10.5 just needs to add a few test cases to get the last parts right.
Pingback:
Pingback:
Pingback:
This is a sweet reference for future use! Thanks!
coollll but in Thailand has still use IE6 = =”
Thanks.
I am using Firefox 3.6.4 and noticed the second row
looked different than what you had for Firefox (3.6.3).
On checking the css, for some reason the br20px10px
class is completely empty.
Hm… I see what you mean. I recently redid the css it looks like I deleted the wrong line from that class when I removed all the -webkit- prefixes. As soon as I can get to the file (it’s complicated) I’ll get that fixed.
Thanks for pointing it out!
As a side effect, however, that does show that Firefox still requires the -moz- prefix as of 3.6.4
Pingback:
if you add
border-left-radius: 0 solid;
(or rather the corresponding -moz-property) to the following example:
border-top: solid 15px;
border-top-left-radius:30px;
it looks like in the spec.
that’s cool because that way you can choose which one you would like to have.
I played with a few permutations of your suggestion (‘solid’ is not a border-radius property, for instance), but nothing I did generated the desired result. If you could test the proper thing to add using firebug and then report back, that would be awesome.
Pingback:
Safari 5 won’t run on my system; I have no choice but to remain with Safari 4, so all your boxes are square.
Hm… I took out the -webkit- prefixes to keep things simpler on my end. In general almost everyone upgrades immediately. I hadn’t considered that Safari 5 might not work on older systems. I should probably go back and put the prefixes back in.
Pingback:
Pingback:
Every once in a while I look at this table and wonder how I’m going to add more browsers, yet keep things simple. I’d love to hear clever ideas, if anyone has one.
Opera’s In! Safari 4 is back, since some people can’t upgrade to 5. Tomorrow I’ll fiddle with the script so when you choose “all” the background will expand to accommodate all the columns.
IE9 is in! Opera is more accurate! Wondering if I should have bothered with Safari 4 (It’s all from memory anyway). The “All” option in the select now expands the whole page to fit all the columns.
Thank you SO much for this. The effort you put in is very appreciated. I found this when I was searching for why I was getting really unexpected rendering in Chrom of the thick, single border scenerio. Really glad it was not my fault; upset that my cute little layout doesn’t work in Chrome.
Thanks for this your table is going to be so helpful and save me so much time when trying to remember which code to use to get each effect.
Pingback:
Pingback:
Pingback:
Hello,
About this form “Leave a reply”: no shadow, no rounded corners with IE9
This is unfortunatly what i’d like to do
Somebody has the solution?
Many thanks
Pingback:
I have found empirically that Safari does NOT support border-radius in %. It’s particularly convenient to create circles or semi-circles using border-radius 50%. Firefox 4+ and Chrome both support this. Need px for Safari.
In fact, the latest Safari finally supports percentages. Hooray!
Pingback:
It seems that Opera 11 has fixed at least one issue with border-radius: /* radius less than border thickness */