the problem with rounded corners/css worries
Translation available in the following language(s):
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.
Shouldn't "overflow" apply here? I notice, however, that you do have "overflow: hidden" set on your UL, and even that's not fixing the problem. Weird.
I put the overflow there to contain the float. I assume though that the problem has to do with a lacking cascading, leaving the nested elements unaware of any rounded corners above.
I guess the apparent overflow on the container is just a result of some graphical trickery, but that's just me guessing.
I recently had the same problem. My solution was to add rounded corners to the child element too. But this is definitely not a pretty way.
For your example this should work for browsers with border-radius support:
Nevertheless it's a workaround.
@Dennis. It should be li:first-child, not ul.
Dennis: yeah, that's how I did it too, but you'll agree with me that it's not what you'd call the preferred way of working. It puts a serious stain on the future implementation of rounded corners.
@Nils: yeah, you're right. @Niels: you too. ;)
Border radius is still a pretty new property, so we can't expect it to work perfectly out of the gate. I think it's a good idea to submit these kinds of findings as bugs to the browser makers so they have a chance to fix them.
There is a similar issue with images inside containers with rounded corners, but it was submitted to the WebKit team, and has been marked fixed and the fix will be included in the next release.
I'm not sure about that. CSS has had weirdness like this for most of its existence, and almost everything else I use has its quirks and corner-cases as well. This is fairly typical of early development in a complex language, and I don't think it's time to start sounding death-knells just yet.
No future for CSS? What will replace it, then? What will replace the internet as well when the time comes?
The current reliance on CSS on modern sights tells me CSS will be around at least for a year or two in the most extreme of cases, but realistically speaking we will still be using some form of CSS even after the apocalypse of 2012.
Personally, I would love to have support for rounded corners in every browser. :3
By the time rounded corners are fully working via CSS in all browsers they will probably be completely unfashionable and look dated anyway (things are heading in that direction already). It amuses me that people think of the web and internet as cutting edge when in reality it often seems like trying to steer a super tanker.
How can the internet be cutting edge... if its edges are already rounded? 83~
Creating context-independent irregular corners was a main problem I have faced while working with css3. There are easy solutions for round corners in css3 but not for all irregular corners. Till I read this article I burned my head thinking about a solution. It’s really an intelligent solution provided here. I have tried it successfully.
* required fields