View Full Version : CSS Rounded Corners?
I'm working on a new design for my personal site, which I think is going to turn out very well. I have one sticking point, though. I need to figure out a way to do rounded corners on a div.
I basically have it set up with a large holder div, which contains four other divs: header, content, nav, and copyright. Header is at the top (duh), content is in the middle on the left, nav is in the middle on the right, and copyright is the footer.
I need to round the top corners of header and the bottom corners of copyright.
I've read several guides to doing it, but I didn't see any that really appealed to me. Any suggestions?
Wait for CSS3? Seriously, there aren't any great ways to do it, I used to a whole bunch of divs until I decided that rounded corners weren't important enough and didn't increase the look of a site enough to justify the work.
Yeah, I know. I think I will just wait. Actually, some browsers support it now, but it's different in different browsers (webkit and firefox/mozilla handle it with different syntax). For now, I'm pretty happy with what I've come up with. I may just go ahead and do it for the browsers that do support it.
Yup. Right now, unless you want to use images and oodles of nested divs, waiting is the only option.
Alternatively, you could start future-proofing today. In some personal pages, I've started using rounded corners by using all three properties: the soon-to-be "official" one, the Mozilla-specific one, and the WebKit-specific one. This method works perfectly for Firefox, Camino, and nightly WebKits and for older browsers downgrades nicely to plain corners:
.roundbox {
-moz-border-radius: 1em;
-khtml-border-radius: 1em;
border-radius: 1em;
}
Do I remember correctly that there was a way to set each specific corner as well? I really only need to set two in each div (although I could just do the holder div).
See here:
http://www.w3.org/TR/2005/WD-css3-background-20050216/#the-border-radius
You can use border-top-right-radius, border-bottom-right-radius, border-bottom-left-radius, border-top-left-radius, and border-radius (all).
For Moz and WebKit, just prepend the "-moz-" and "-khtml-" prefixes.
Yeah, I know. I think I will just wait. Actually, some browsers support it now, but it's different in different browsers (webkit and firefox/mozilla handle it with different syntax). For now, I'm pretty happy with what I've come up with. I may just go ahead and do it for the browsers that do support it.
Alternatively, you could start future-proofing today. In some personal pages, I've started using rounded corners by using all three properties: the soon-to-be "official" one, the Mozilla-specific one, and the WebKit-specific one. This method works perfectly for Firefox, Camino, and nightly WebKits and for older browsers downgrades nicely to plain corners:
.roundbox {
-moz-border-radius: 1em;
-khtml-border-radius: 1em;
border-radius: 1em;
}
Okay, officially confused. The syntax looks the same except for the layout engine prefix. So why do you need to specify the browser before the syntax at all? The syntax looks the same to me. Why wouldn't this:
.roundbox {
border-radius: 1em;
}
work on both WebKit and Mozilla?
Okay, officially confused. The syntax looks the same except for the layout engine prefix. So why do you need to specify the browser before the syntax at all? The syntax looks the same to me. Why wouldn't this:
.roundbox {
border-radius: 1em;
}
work on both WebKit and Mozilla?
Because it's not an official spec yet.
Unofficial specs are created by browser-makers to be browser-specific like that. Mozilla has its own set of properties that don't work in other browsers, just as WebKit and Safari have sets of properties that don't work in other browsers.
For example, when Safari (official version) sees -moz-border-radius, -khtml-border-radius, or border-radius, it doesn't know what to do with them and they are all ignored, giving you regular square corners. However, WebKit is coded to recognize -khtml-border-radius and format corners accordingly.
On the other hand, Mozilla/Firefox/Camino doesn't know what to do with -khtml-border-radius or border-radius, but it does have a special case for -moz-border-radius.
Why?
Since it's not an officially agreed-upon spec, they may behave very differently. Thus, it's safer to "turn them off" or hide them like this until everything is golden.
Okay got it. So the prefix is basically telling the browser to "turn on" this draft spec, because its "off" by deafult.
Basically, yeah.
It's not just about a "-khtml-" prefix, though. It's that whole property. A web browser keeps a list of CSS properties it knows how to handle, just as it keeps a list of HTML tags it can handle. Regarding this CSS property, WebKit simply does not have an entry in that list called "border-radius". WebKit does, however, have an entry in that list called "-khtml-border-radius" which behaves roughly the same as the spec for "border-radius". Since for now it's a proprietary implementation, though, the developers are using a proprietary property name.
Once either the spec becomes official or the behavior of the "border-radius" property is universally agreed-upon, then the makers of WebKit (and Mozilla, et al.) will add "border-radius" to that list of properties the browser can use.
Actually, plain border-radius works just fine in dev builds of Safari, at least in my experience.
khtml-border-radius does still work though, and -moz-border-radius is still necessary in FF.
If you don't want to wait for CSS3, then try this out:
http://www.webreference.com/programming/css_borders/examples/krazy.htm
drewprops
2006-07-30, 12:59
I use the sliding doors method over at http://www.piratepalooza.com with pretty good results. Items in the sidebar are in boxes with rounded corners and individual posts look like worn and nicked parchment, stretching to fit long tracts of text fairly well. Took me bloody forever to burn the idea into my brain... happy with the result though.
There's a not insignificant chance that CSS 3 won't ever see the light of day, so "make the most of what you have now" would be my advice.
There's a not insignificant chance that CSS 3 won't ever see the light of day, so "make the most of what you have now" would be my advice.
That doesn't mean that UAs won't move on implementing the useful bits. Even if the CSS3 specs never get approved, I think there's still a reasonable chance of adoption of significant parts of them. With IE back in active development, we can hopefully look forward to improved competition amongst browsers over things like the coolness of CSS3.
That doesn't mean that UAs won't move on implementing the useful bits. Even if the CSS3 specs never get approved, I think there's still a reasonable chance of adoption of significant parts of them. With IE back in active development, we can hopefully look forward to improved competition amongst browsers over things like the coolness of CSS3.
Very true. I thought the MSIE team had finished fucking with Trident for this version, though? Isn't it going to be IE8 before we see any further rendering engine enhancements or functionality additions? I could well be wrong, they might have meant they were going to start with the spit-in-my-hand gesture that they've given us already and then build on it as and when they are given scope for new iterations.
Either way, Trident sucks and MSIE are putting a lot of good, talented developers to waste.
Very true. I thought the MSIE team had finished fucking with Trident for this version, though?
Correct. Development on IE7's rendering engine has been frozen for months. Whatever works or fails in the current beta will be the same in the final release.
That's awesome news! It would have been cheaper to send a mixed bag of softcore gay porn, pufferfish poison disguised as candy and Sour Grapes on VHS to every web developer worldwide, and it'd have done about as much good too.
Thank fuck Vista's development is going swimmingly, that's all I can say.
vBulletin® v3.6.4, Copyright ©2000-2024, Jelsoft Enterprises Ltd.