the problem with rounded corners

Rounded corners. They were already a big deal a couple of years ago, and even though several solutions exist today, they still present a hurdle which can't be taken with much grace. When css3 was revealed, one of the first announced features was the border-radius property, enabling us to apply rounded corners through css. Remember how happy we all were? Hold that thought, and run through this article to see how that idea is already failing, even before it found its way into each modern browser.

how things will be

Some time ago we ran into a design that required rounded corners on a transparent container. Since we didn't want to use javascript, we started looking into other options, finally settling for some good old graceful degradation. The latest versions of Firefox and WebKit (Safari and Chrome) both have their own properties to render rounded corners using css. Their use is relatively simple and the result pretty neat.

div {border-radius:10px;}

The code above demonstrates the easiest use as defined by the guidelines of the w3c. This statement creates rounded borders, created by a 10px-radius circle. Beyond that, it is possible to set separate values for both horizontal and vertical radius and for each corner separately. Considering the scope of this article though, the above statement is all we really need.

a little test case

A week or so ago I was trying out some small designs in html and since I needed rounded corners I figured I could just as well use the Firefox property (it was only a design exercise after all). What I needed was a horizontal navigation bar with 4 rounded corners. A rather simple case, so I added the rounded borders on the ul, floated the li elements and added some finishing touches for active and hover states. That's where it started to fail.

Firefox and WebKit have their own border-radius implementations for now, so we'll use those to build and demonstrate our test case. The test page contains a simple horizontal navigation setup (without any fancy designs), so have a quick look to get a better understanding of the situation (and problem) at hand.

navigation bar with rounded borders test page
(only works in supporting versions of Safari, Firefox and Chrome)

what went wrong

The problem is all about expectations. In our head, rounded corners (and borders) are more than simply a design element. If you put borders on a container and you round them, the container becomes everything what's inside the area between the borders. The area outside the rounding is not part of the container anymore. The w3c specs seem to take this into account, as background colors and images on the container are equally capped.

What is still missing are rules that state the behavior of elements nested inside the container. In our example above, this means the list and link elements. Even though the ul (container) received rounded corners, the link elements seem unaware of that, so when they have a background set they overlap the rounded corners. I don't think anyone would consider this logical or even preferred behavior. If you go back to the test page and you hover over the first li element you'll notice how this isn't exactly what you'd expect it to be.

fix it

There are of course workarounds, but none of them are very graceful. You could place the borders on the link elements, but then you have to worry about double borders and getting those roundings on the right side of the bar. Another option is to leave the main border on the ul and to pull the first li element over the border using negative margins, then apply the same roundings to that li element.

There are probably other solutions, but there is a reason why I'm not explaining them in full, or even bother to get them across in any clear way. An implementation like this is simply not feasible, and I can't imagine that, when we'll finally be able to use the border-radius property in our every day work, we'll have to deal with simple things like this. If that's how the implementation will be in 5 years time, the property is already a failure to me.

It's an issue I'll report to the people taking care of the css3 specs, and let's hope they take it to heart. If not, it's hard to imagine a solid future for css, as basic problems like this will finally turn away even the most hardheaded coders.