Three years and ten days ago, the Webkit team first implemented the
border-radius CSS property. It’s part of the CSS3 Backgrounds and Borders Module working draft. Unfortunately, it still is a working draft today and as we’ll see, there are still some issues to be resolved.
A neat behavior of the Gecko implementation of
border-radius but missing in WebKit is the fact that it accounts for values that are too high. If you’d have a box with a height of 100px and a
border-radius of 51px, Safari figures it can’t draw those corners and defaults to square corners. This is really annoying in cases where an element doesn’t have a fixed height and you just want the corners to be as round as possible. Compare WebKit vs. Gecko in this test.
This topic has been described in detail on the css3.info website. It boils down to the fact that although the Firefox shorthand syntax of
border-radius looks easier, it doesn’t allow irregular curves with different horizontal and vertical values. You’d have to resort to commas for a complete shorthand syntax, but for now I’m fine with the WebKit syntax.
Dotted border style
border-radius on a dotted border, Firefox seems to be caught in a weird loop, applying the radius on the individual dots of the border as well. I made a small test-suite for this issue too.
Artifacts in Safari
Firefox 2 had really sloppy rounded corners — they were aliased. Firefox 3 fortunately solved this, and now they’re just as smooth as their Safari counterparts1. In fact, I even prefer the Firefox rendering because Safari seems to be dealing with ‘artifacts’ along the edges on some backgrounds. Take a look at this test:
There was an issue in Gecko 1.8 with background images not being clipped along the outer edges of the border. Gregory Reimer made an excellent roundup back in February 2007, but this was fixed too for Gecko 1.9/Firefox 3. No more ugly corners sticking out of your rounded boxes!
I love the
border-radius property because it’s one of those features that perfectly degrade in non-supporting browsers. They simply get square borders — no harm done. Over the years we’ve seen more and more sites picking it up. Let’s hope that these small differences will soon be ironed out, so the spec can be updated and other browsers can implement the
Someday we’ll be able to make buttons like these without any images, in all browsers:
- I’m specifically saying Safari here, because the rendering is up to the graphics library. The current beta of Google Chrome suffers from aliased edges in their Skia cross-platform graphics library, although they’re using WebKit. [↩]
Keep an eye out for the next draft of this module. (Should be published in a week or two.) It tackles the shorthand syntax issue and specifies behavior for intersecting curves in excruciating detail. 🙂
That’s great news fantasai!
[…] as fantasai promised in a comment on my previous blog post, we heard about the new level 3 draft of the backgrounds and borders module at the conference. I […]
[…] border-radius today provides nice, rounded corners and shaves a ton of development time (no more round-trips to the image editor or nesting HTML for […]
Since you’re -webkit- prefixing for Safari and Chrome, you could -moz- prefix for Firefox etc – much like the 24ways 2008 buttons