border-radius: Safari vs Mozilla
With the release of Safari 3, there are now two browsers with (browser-specific) implementations of border-radius; unfortunately, the two implementations are different. The problem is that there is an unresolved ambiguity in the CSS 3 working draft.
The draft proposes four declarations, which describe the four corners of a block:
border-top-left-radius border-top-right-radius border-bottom-right-radius border-bottom-left-radius
Each of them should accept two values, which define the radii of a quarter ellipse that defines the shape of the corner
; this allows for irregular curves (take a look at the diagram in the draft if you need clarification, or see this example of a box with border-radius: 5px 20px, horribly rendered in Safari for Windows).
Safari, with the prefix -webkit-, accepts these. Mozilla, with the prefix -moz- (and differing declarations), accepts only a single value and, therefore, only regular curves.
At first glance, it would appear that Mozilla are in the wrong; however, their implementation is due to the ambiguity I mentioned earlier.
This ambiguity comes about in the border-radius shorthand property; if you enter a double value in this you’d expect to apply the irregular curves to all four corners:
border-radius: 5px 10px;
If you wanted to have four different irregular curves on the box, you’d have to provide eight values to the declaration:
border-radius: 5px 20px 10px 5px 10px 20px 20px 5px;
But what if you wanted to have two corners with one value, and two corners with a different value?
border-radius: 5px 10px 10px 20px;
The problem is that this could be confused for four corners with regular curves. In order to get around this, you’d still have to provide eight values:
border-radius: 5px 5px 10px 10px 10px 10px 20px 20px;
In fact, from the brief testing I’ve done (and I can’t find any documentation), it seems you can’t do any of that; unless I’m missing something, the shorthand declaration in Safari accepts only 1 or 2 values, to provide either regular or irregular curves which are applied to all four corners. If you want different irregular corners, you have to supply values to all four declarations:
border-top-left-radius: 5px 20px; border-top-right-radius: 10px 5px; border-bottom-right-radius: 10px 20px; border-bottom-left-radius: 20px 5px;
Mozilla avoid this by going against the spec and allowing only regular curves; so you can provide 1, 2, 3 or 4 values and it’s all perfectly clear.
This problem is down to interpretation of the draft. I personally think Mozilla’s non-standard solution is better - it’s less flexible, but easier to understand - but can’t blame the Safari team for following the standard in their implementation.
It will be interesting to see which comes out on top; in the meantime, if you want to use border-radius in your code the only way to get them to appear the same on both browsers is with a single value for four regular corners:
-moz-border-radius: 10px; -webkit-border-radius: 10px;
Good piece Peter :) have you, by any chance, tested how Konqueror behaves with this as well?
I’ve read that Konqueror supports -khtml-border-radius, but can’t find any official confirmation, and can’t get it to work.
Could you attach a screenshot of such a irregular curve ?
I’ve added an example of -webkit-border-radius: 5px 20px to the post; I have to say, the rendering is horrible. I’m not sure if that’s because it’s Safari for Windows, perhaps someone with an OS X version could try?
Maybe it’s an idea to add a character like / to the value, like in
font. So what’s before the character is the X radius, and after the character is the Y radius. If the character isn’t used, the value will be for both the X and Y radius. So now you can have something like this:border-radius: 5px/20px 10px/5px 10px/20px 20px/5px;Good idea, Arjan; a slash or a comma, like font-family uses:
border-radius: 5px 20px, 20px, 10px 20px, 20px;
I wonder if irregular curves are the way to go, however; the current implementation in Safari is horrible, whereas regular curves come out looking really nice.
Just to clarify, you *can* get identical rendering on WebKit and Gecko with a different radius on each corner. You just have to use the individual properties like
-webkit-border-top-left-radiusand-moz-border-radius-topleft. I’ve been using that technique to create tabs with rounded corners since I started playing with WebKit nightlies a few months ago.And after messing around with that irregular-corner code, I think the reason it looks bad is that the smaller radius of 5px is the same width as the border. If you use a narrower border, like 1px or 2px, or if you use the 5px border with 20px and 40px for the radius, it looks fine.
CSS3 gathering speed……
over at CSS3, Paul Gasston has been diligently track the adoption and implementation of all things CSS3. His latest post concerning rounding corners highlights the frustration……
Diferencias entre el uso de border-radius en safari 3 y mozilla…
Un artículo acerca del diferente tratamiento que se ha dado a la propiedad border-radius en Safari 3 y Mozilla. Por lo visto viene de una mala intepretación de la especificación…
[...] Originally posted on CSS3.info. [...]
Safari on Mac OS X renders exactly the same. But I do agree with Kelson, if the border size isn’t the same as the minor size, it looks much better.
Hmm, confusing. Though, I don’t see a problem with forcing the shorthand declaration to only take 4 values (one for each corner, regular only) whilst allowing non-regular corners with the individual declarations; it wouldn’t be the first shorthand property to not allow every aspect to be specified at once.
How can you say that screenshot from Safari is horribly rendered? It’s not as good as it should be, sure, but Firefox makes border-radius look like ass… It’s much better to avoid it at the moment, if you’re targetting FF, as it looks really pixellated and awful. See my work in progress (link below) and compare the beautiful rendering in Safari to FF’s piss-poor attempt.
I say stick with images till this stuff gets sorted out.
I think the inside of that border IS rendered horribly, but I’m sure if you matched the internal colour to the border it would look great.
Firefox 3’s corner rendering is better than FF2’s, judging by the preview I’ve been playing with.
It probably is safer to stick to images until this gets sorted out, I agree; although, it would be better if we could have multiple background images!
There’s another difference between the two that you haven’t brought up. If you apply a background picture to e.g. add some depth to what you’re making, Mozilla won’t clip it, so you’ll end up with square corners. Safari does the logical thing and applies the border radius to the background image as well.
It’s acknowledged in their bug database, but if it’s time to fix it for FF3 is another matter.
https://bugzilla.mozilla.org/show_bug.cgi?id=24998
Peter: I believe you’re right on that one, the outside is better than the inside, but it’s still not perfect. I don’t test against/use FF3 at all, so that’s cool if it is indeed better.
I suppose this kind of thing is the peril of playing with pre-spec stuff, but it does rather take the p**s that in 2007 we still can’t make a box with pretty rounded corners programmatically.
Meanwhile, Safari has apparently supported multiple background images since the dawn of time (well, for ages, anyway) - although I only found out a few weeks ago.
you *can* get identical rendering on WebKit and Gecko with a different radius on each corner. You just have to use the individual properties like -webkit-border-top-left-radius and -moz-border-radius-topleft.
Kelson - what do you do for Opera ?
@Anjanesh: You don’t. Opera has no border-radius implementation at the moment.
Prince also supports the border-radius properties, accepting two values on each.
Interesting article and certainly shows that CSS3 could become unnecessarily complicated and I’d tend to agree with Mozilla’s interpretation of the spec.
There’d also be the option of using border-image once this has been more widely adopted for any complicated irregular borders.
[...] border-radius: Safari vs Mozilla July 17th, 2007 — mozienigma border-radius: Safari vs Mozilla [...]
For what it’s worth, Mozilla has implemented -moz-border-radius since before it was in any css3 draft (see cvs history; note revisions 3.59 and 3.98). The first W3C draft I could find with border-radius was much later. I don’t recall if the differences between them are simply the editor’s preference or whether the working group has actually discussed which is preferable.
I’d just like to note that thanks to this discussion the CSSWG has adopted Mozilla’s shorthand syntax. :)
[...] our discussion of the inherent ambiguity in the border-radius declaration, it has been decided that the simpler syntax used by Mozilla will used for the shorthand; that is, [...]
[...] κάποιο τρόπο να τα αντικαθιστά και τα 2 με ένα query λόγω ασυμβατότητας μεταξύ των implementations του κάθε browser. Για να ξεπεραστεί αυτή η ασυμβατότητα το πρώτο [...]
[...] Podeis obtener más información sobre la propiedad border-radius, y como la interpretan los navegadores que la soportan en este artículo: border-radius. Apple vs Mozilla. [...]