Open
Bug 431176
(border-radius)
Opened 17 years ago
Updated 6 months ago
[meta] Tracking bug for remaining issues with CSS3 border-radius
Categories
(Core :: CSS Parsing and Computation, defect, P3)
Core
CSS Parsing and Computation
Tracking
()
NEW
People
(Reporter: netrolller.3d, Unassigned)
References
(Depends on 9 open bugs, Blocks 1 open bug)
Details
(Keywords: meta)
Attachments
(1 file, 1 obsolete file)
1.44 KB,
image/gif
|
Details |
CSS3's border radius property is not currently implemented in Mozilla. There is -moz-border-radius, but it's buggy and doesn't match the spec. This bug is about implementing the standard CSS3 border-radius property. For this, the following are needed: *Get elliptic corners work, *Handle the interaction of border-radius and border styles (for example, dotted), *Fix this: when two different dashed/dotted borders intersect in a radiused corner, the transition is not smooth. I will describe a possible solution in detail later. Elliptic corners in themselves wouldn't be hard, as long as the borders are not dashed/dotted. However, if they are, then problems arise: where exactly should we put the dots/dashes? A proof-of-concept implementation of this in Javascript is available at http://verens.com/demos/borders/dashed-curve.html. About the third case: Assume that a 10px blue dotted border intersects with a 15px red dotted one, in a corner with border-radius: 50px 20px. The problem: at which point of the curve should we switch from 10px blue to 15px red? The solution: don't "switch" - do a smooth transition instead. Essentially, going from the first border to the second through the curve, each dot gets a bit bigger than the previous one, and the colors of the dots slowly shift from blue to red. I think that during this color transition, each dot should have a solid color, and not a gradient. (AFAIK the spec doesn't specify this transition case.) At a dash-dash intersection, the dashes should be drawn as segments of a gradient-colored solid border. At a dash-dot intersection, we should decide at a cut-off point where we switch from dashing to dotting. I suggest 50% of the curve. The last dash on the curve should be drawn with a rounded-off end. I case of a color difference, the dashes (including the final, rounded one) should be gradient, while the dots should be solid-colored. At a solid-dash intersection, the solution is simple: do a continuous color transition, and start dashing @ 50% of the curve. At a solid-solid intersection, simply draw a gradient transition (if the specs allow it). (http://verens.com/demos/borders/dashed-curve.html gets these color transitions wrong.) At a double-solid intersection, we should reduce the width of the groove in the double border, until it blends into the solid one. (This might be tricky!) At a solid-dot intersection, we should start dotting @ 50%. Again, the solid part should be gradient, while the dots should be solid colored (bot each dot different from the previous one). In case of a size difference, make the size of the dots shrink/grow continuously. The ending of the solid part should be rounded off. At a double-dotted intersection, the switch should again be @ 50%, The double borders should curve together, into a rounded loop. I case of a double-dashed intersection, no curve-up is needed. Note however that most of these curve-up/transition things are cosmetic issues, and not really needed for spec compliance.
Yeah, dupe, but Stefanik has a better writeup of issues and ideas here. Stefanik, if you do decide to tackle this, I would strongly urge you to keep going with the proof-of-concept work first; implement the border rendering in JS using canvas first, as essentially the same drawing operations are available internally. That's how I did much of the original thebes border code (though I can't find my test harness at the moment to pass it on =/). However, I don't think that gradients at intersections are the right thing to do; so far there has always been a clean break between border colors at corner joins, and I don't think that border radius should modify that.
I believe the CSS WG came up with wording that explains where the color change should be, and how the radius should work when the thicknesses of the two sides are different. See the editor's draft at http://dev.w3.org/csswg/css3-background/#the-border-radius
Comment 5•17 years ago
|
||
Adding this to the 1.9.1 triage queue by marking this wanted1.9.1?.
Flags: wanted1.9.1?
Priority: -- → P2
Flags: wanted1.9.1? → wanted1.9.1+
Michael, Vlad says his border patch (bug 424423) handles the rendering side of this, all we need is the style system properties. Perhaps something to keep you busy :-).
Comment 9•16 years ago
|
||
The spec seems to have changed quite drastically between http://www.w3.org/TR/css3-background/#the-border-radius and http://dev.w3.org/csswg/css3-background/#the-border-radius especially wrt the shorthand property: 2005 TR: border-radius: <length> <length>? # equivalent to setting all four border-<corner>-radius props # to the same value # for all border-*radius, which is horizontal and which is vertical depends # on the writing-mode 2008 ED: border-radius: <length>{1,4} [ '/' <length>{1,4} ]? # the numbers apply to TL, TR[=TL], BR[=TL], BL[=TR] in that order # horizontal before the slash, vertical after # no mention of the writing-mode for any of the props Unless I hear otherwise I'm going to implement the 2008 ED spec. Also, details of the interaction with border styles at the corners may not be 100% in the first pass. Also, I'm assuming there's no need to support the -webkit- variant of these properties.
Status: NEW → ASSIGNED
Comment 10•16 years ago
|
||
grrr, assignment UI still doesn't work the way I think it does.
Assignee: nobody → zweinberg
Status: ASSIGNED → NEW
Updated•16 years ago
|
Status: NEW → ASSIGNED
(In reply to comment #9) > Also, I'm assuming there's no need to support the -webkit- variant of these > properties. Correct, we never want to implement another vendor's vendor-prefix properties.
Comment 12•16 years ago
|
||
(In reply to comment #9) > Unless I hear otherwise I'm going to implement the 2008 ED spec. Also, details > of the interaction with border styles at the corners may not be 100% in the > first pass. I think that's exactly what you should do. In terms of test cases, that's what we should look for: - identical / different horizontal and vertical radii - interaction with the border width if different for horizontal and vertical values => different radii for inside and outside the border - change of style / colour limited to a sharp change at 45˚ or on the diagonal of the rectangle that envelops the rounded corner > Also, I'm assuming there's no need to support the -webkit- variant of these > properties. Absolutely right, keep to the standard, it's complex enough without introducing variants.
(In reply to comment #12) > (In reply to comment #9) > > Unless I hear otherwise I'm going to implement the 2008 ED spec. Also, details > > of the interaction with border styles at the corners may not be 100% in the > > first pass. > > I think that's exactly what you should do. In terms of test cases, that's what > we should look for: > - identical / different horizontal and vertical radii > - interaction with the border width if different for horizontal and vertical > values => different radii for inside and outside the border > - change of style / colour limited to a sharp change at 45˚ or on the diagonal > of the rectangle that envelops the rounded corner If all that changes is the parsing, and we get the radii down to CSS border rendering, those three should be working correclty now -- for the last point, currently the change happens along the horizontal from the outer corner to the inner corner of the border region (for any particular corner), so for transitions between a really thick border and a really thin border it won't be 45 degrees.. but it's not clear whether 45 degrees would look better there anyway.
Comment 14•16 years ago
|
||
The spec actually asks for something a little more subtle: The center of color and style transitions between adjoining borders is at the point on the curve that is at an angle that is proportional to the ratio of the border widths. For example, if the two widths are equal, that point is at a 45° angle, and if one is twice the width of the other the point is at a 30° angle. The line demarcating this transition is drawn between the point at that angle on the outer curve and the point at that angle on the inner curve. The transition must be contained within the segment of the border where the tangent of the inner curve either not defined or is not parallel with the sides of the box. It is not defined what the transition looks like, but a gradient is recommended for color transitions. This is what I'm saying I'm not going to do in the first pass. :)
(In reply to comment #9) > Unless I hear otherwise I'm going to implement the 2008 ED spec. Also, details > of the interaction with border styles at the corners may not be 100% in the > first pass. Right. The 2008 spec is a superset of what we already implement; the 2005 spec was not. It should still be -moz-* prefixed until the spec in question is in CR.
Comment 16•16 years ago
|
||
I can't find the exact point in the spec where it specifies this but I seem to remember that a rounded corner between borders of different thickness is meant to be smooth, as illustrated in the attached GIF.
Comment 17•16 years ago
|
||
Bruno: see figure 8 in http://dev.w3.org/csswg/css3-background/#the-border-radius (you'll have to scroll down a bit).
Comment 18•16 years ago
|
||
Zack: Ah yes! I knew there was a relevant figure somewhere but Firefox 3.0.1 on my Mac wouldn't show it at first for some reason. I think I'll go write a bug report :-)
Comment 19•16 years ago
|
||
You probably already know this, but just to make sure it doesn't become an issue, make sure the code that clips the background corners and paints the box-shadow also gets updated.
So, really, this should probably be split into a bunch of dependencies: 1. support for the extended syntax for the shorthand 2. any graphics changes needed to match the spec (maybe more than one bug) 3. [once the spec hits CR] renaming -moz-border-radius to border-radius
Reporter | ||
Comment 21•16 years ago
|
||
We might want to call this property -moz-new-border-radius (until it's CR of course), to avoid conflicts with existing uses of -moz-border-radius.
(In reply to comment #21) > We might want to call this property -moz-new-border-radius (until it's CR of > course), to avoid conflicts with existing uses of -moz-border-radius. No, we don't. The syntax is a superset of the current syntax.
Comment 23•16 years ago
|
||
I'm working on the style system part of this in bug 450652 now. One thing that's already come up is, the spec has different longhand property names: currently we have -moz-border-radius-topleft etc. where the spec uses border-top-left-radius etc. I have prepared a large, mechanical patch that converts to -moz-border-top-left-radius etc. but I'm wondering if that's worth doing, given that they'll just have to be renamed *again* when the spec hits CR. Also, there is existing logic to implement backward compatibility aliases for the CSS property names, but AFAICT not for JS element.style.property notation - those change too, e.g. .MozBorderRadiusTopleft becomes .(Moz)BorderTopLeftRadius. Is this a problem?
(In reply to comment #23) > One thing that's already come up is, the spec has different longhand property > names: currently we have -moz-border-radius-topleft etc. where the spec uses > border-top-left-radius etc. I have prepared a large, mechanical patch that > converts to -moz-border-top-left-radius etc. but I'm wondering if that's worth > doing, given that they'll just have to be renamed *again* when the spec hits > CR. I'd slightly prefer to match the CSS3 syntax as closely as possible modulo the vendor prefix, since it makes life easier for authors who are using it (who will probably want to use -webkit-border-top-left-radius etc as well). > Also, there is existing logic to implement backward compatibility aliases for > the CSS property names, but AFAICT not for JS element.style.property notation - > those change too, e.g. .MozBorderRadiusTopleft becomes > .(Moz)BorderTopLeftRadius. Is this a problem? I think it's not a problem.
Comment 25•16 years ago
|
||
Ok. I've just attached my patch to that effect to bug 450652. More tomorrow.
Note that I'm all for border-top-left-radius, but I think we may need to keep the -moz-border-radius-topleft as an alias; there are a ton of themes out there that use that spec. We should get rid of it when the spec goes into CR.
Comment 27•16 years ago
|
||
(In reply to comment #26) > Note that I'm all for border-top-left-radius, but I think we may need to keep > the -moz-border-radius-topleft as an alias Yup, it's in there (look for gAliases in nsCSSProps.cpp)
Reporter | ||
Comment 28•16 years ago
|
||
By the way, the "2005 TR vs. 2008 ED" question is no longer relevant - implement the new 2008 TR.
Comment 29•16 years ago
|
||
Adding bug 448193 as there is a regression on border-radius with outset/inset/ridge/groove borders which makes us fail any standards compliancy testing on this combination.
Depends on: 448193
Reporter | ||
Comment 30•16 years ago
|
||
(In reply to comment #29) > Adding bug 448193 as there is a regression on border-radius with > outset/inset/ridge/groove borders which makes us fail any standards compliancy > testing on this combination. Please actually add it, not just talk about adding it. (By the way, I added it.)
Depends on: 448193
Comment 31•16 years ago
|
||
He added it, but I took it off (which I have now done again). Please see the discussion in 448193 for why.
No longer depends on: 448193
Comment 32•16 years ago
|
||
The core feature has landed; it doesn't make sense to have this cluttering up the wanted1.9.1+ list anymore. Retitling to make present state of bug clearer.
Flags: wanted1.9.1+
Summary: Implement the CSS3 border-radius property → Tracking bug for remaining issues with CSS3 border-radius
Comment 33•16 years ago
|
||
adding some deps: - bug 382721 (dots and dashes don't continue around corners) - bug 459945 (stripe borders have the wrong curve in between stripes)
Reporter | ||
Comment 34•16 years ago
|
||
There is actuaally one more problem, though no bug has been filed for it: there are no color transitions between different-colored borders.
Comment 35•16 years ago
|
||
Thanks, I'd forgotten that one. Filed bug 483696.
No longer depends on: 483696
Comment 36•15 years ago
|
||
-moz-border-radius doesn't work on IMG tag (on Firefox 3.5.5 and 3.6b3) without a border width specified. And if you specify this width, the "border" is rounded outside and squared inside. So, -moz-border-radius cannot be used on the same way -webkit-border-radius is used : putting rounded corners on an IMG tag without any tricks (like using a div with border radius and the IMG as background).
(In reply to comment #36) > -moz-border-radius doesn't work on IMG tag (on Firefox 3.5.5 and 3.6b3) without > a border width specified. > And if you specify this width, the "border" is rounded outside and squared > inside. This sounds like bug 485501. (I'm assuming you mean that the border gets rounded but the image itself doesn't get clipped at all.)
Comment 38•15 years ago
|
||
Yes, the border is rounded but not the image (in fact, I thought border-radius would act as a "corner-radius" (if it existed) should work, but the border-radius use is a little bit different)
Depends on: 537433
Updated•15 years ago
|
Comment 40•15 years ago
|
||
I just went through and added every bug I could find with 'border-radius' in the subject line to the dependencies of this bug, except the ones that I could prove had already been fixed. Some of the remaining bugs may also have already been fixed, and some of the others may be duplicates of each other. Bringing over what I just said in bug 395674: I think that before we drop the -moz- prefix on these properties, we should at a minimum fix bug 485501 (clip images to the border-radius) and bug 471643 (vertical percentages should be relative to box height, not width). Bug 459144 (clip *all* content to the curve when overflow!=visible) and bug 382721 (dotted/dashed corners drawn as solid with border-radius) would also be nice but may be much harder to fix so I'm reluctant to make them block the property name. I don't know if I'll have time to work on any of this in the near future.
Whiteboard: qawanted
I don't think bug 459144 would be very hard to fix.
Comment 42•15 years ago
|
||
dbaron was pessimistic about that 'way back when (I think it was on IRC) but it might be easier now that scrollframes don't have views.
You just need a new display item, like nsDisplayClip but different.
![]() |
||
Comment 44•15 years ago
|
||
Could we drop the -moz prefix now? Even IE9 has: http://blogs.msdn.com/ie/archive/2010/03/19/the-css-corner-about-css-corners.aspx
Reporter | ||
Comment 45•15 years ago
|
||
And indeed, the spec is CR now. There is no reason to prefix it anymore.
Comment 46•15 years ago
|
||
The prefix should remain while there are still major bugs. See comment 40.
Updated•15 years ago
|
Comment 47•14 years ago
|
||
Safari 5 no longer has the -webkit- prefix for border-radius, so by the end of this year Firefox could be the only major browser without spec-compliant border-radius implementation.
Comment 48•14 years ago
|
||
Is webkit's actually spec-compliant? I thought (a) the specification wasn't finished, and (b) the webkit implementation differed from the current/latest specification
Comment 49•14 years ago
|
||
(In reply to comment #48) > Is webkit's actually spec-compliant? I thought (a) the specification wasn't > finished, and (b) the webkit implementation differed from the current/latest > specification Well the spec is still at Working Draft status, but Opera, WebKit (and soon IE9) all comply with the syntax that's in the current version - at least, I haven't run a battery of tests on it, but they all support it for length units (although not percentages) - that is, they all support the border-radius syntax with the slash, and all without the prefix.
![]() |
||
Comment 50•14 years ago
|
||
(In reply to comment #49) > Well the spec is still at Working Draft status, but Opera, WebKit (and soon > IE9) all comply with the syntax that's in the current version - at least, I > haven't run a battery of tests on it, but they all support it for length units > (although not percentages) - that is, they all support the border-radius syntax > with the slash, and all without the prefix. Recognizing the W3C syntax does not necessarily imply specification compliance of the implementation. That would be like saying: just because the word 'smoking' also exists in French, if you ask for 'smoking' in France, you won't necessarily get anything related to a cigarette. (In fact, you'll probably get a tuxedo.)
Comment 51•14 years ago
|
||
I think we're going a little off topic here, its not important if or how well other browser developers have implemented this, its how Gecko handles 'border-radius' that's important. I would love for Fx4.0 to at least drop the vendor specific prefix as I think it implements -moz-border-radius pretty well, and as its now the only browser (of the top 4) to not render anything for border-radius in their latest builds, it would be a shame if developers must add border-radius and then -moz-border-radius to implement this cross-browser.
Comment 52•14 years ago
|
||
Aside from the box-shadow section, the rest of the spec is effectively in CR. So the spec there is finished. As for Webkit's implementation, last I checked they did have spec compliance bugs. FWIW, I agree with Zack's comment 40.
Comment 53•14 years ago
|
||
Up to dbaron/zweinberg to determine if they think that dropping the vendor prefix should block Firefox 4, and if that's the case we'll need a bug on that with the specific fixes required (maybe taking the list from comment 40) marked blocking2.0 I agree that removing the vendor-prefixes has WIN all over it, assuming that what we implement is what web authors will expect from non-vendor-prefixed descriptors.
Comment 54•14 years ago
|
||
(In reply to comment #53) > Up to dbaron/zweinberg to determine if they think that dropping the vendor > prefix should block Firefox 4 I want to say yes (given that all other vendors have, and we're taking flak) but, um, here I am dropping from full time to unpaid volunteer with very limited coding time as of Friday, and it appears that nobody else has time to do it either.
Comment 56•14 years ago
|
||
I have made the bugs listed in comment 40 ( bug 485501, bug 471643, bug 459144 ) block bug 471643, which is the bug that says "we should drop the vendor prefix". dbaron agrees that these are the things that need to get fixed first.
Comment 57•14 years ago
|
||
I no longer work for Mozilla, I am deassigning myself from bugs I have no intention of working on as a volunteer.
Assignee: zackw → nobody
Status: ASSIGNED → NEW
Depends on: 593717
For the record, I just filed bug 593717 on making outlines follow the border-radius curve instead of having a separate -moz-outline-radius. My current thinking is that this does NOT block renaming -moz-border-radius to border-radius (bug 451134). I also have patches in progress for the two remaining bugs that we agreed do block it.
No longer depends on: 596205
Blocks: css3-background
Depends on: 383030
Depends on: 664154
Comment 60•12 years ago
|
||
(In reply to Florian Bender from comment #59) > Bug 760358, Bug 652650 and maybe Bug 697645 should be added. Concur. For future reference, you can do that yourself by clicking on the (edit) next to the list of bugs that this one depends on (way up at the top) and then adding the bug numbers to the text box that appears.
Comment 61•12 years ago
|
||
For dashed borders, you can check https://bugzilla.mozilla.org/show_bug.cgi?id=652650 There is a implementation that I had implemented based on spec. Handles dashed borders along the elliptical corners. How it looked in firefox : http://gsocwithmozilla.wordpress.com/2011/07/31/basic-patch/. More sample output : https://github.com/anilshanbhag/border/tree/master/sample%20output. There is also a python implementation in pycairo used for reftest generation.
Comment 62•11 years ago
|
||
The latest version of Firefox (22.0) is worse than the previous one... I have a button whose style is as follows: border-radius: 2em 2em 2em 2em; font-size: 110%; padding: 0.5em 1em; min-width: 7em; padding: 1px 1em; This rendered fine with earlier versions of Firefox, but now the rounded courners are rotated in some weird way. A screenshot for Firefox is here: https://dl.dropboxusercontent.com/u/18254707/button_firefox.jpg The same thing with Chrome is here: https://dl.dropboxusercontent.com/u/18254707/button_chrome.jpg
Comment 63•11 years ago
|
||
(In reply to John from comment #62) > A screenshot for Firefox is here: > https://dl.dropboxusercontent.com/u/18254707/button_firefox.jpg > The same thing with Chrome is here: > https://dl.dropboxusercontent.com/u/18254707/button_chrome.jpg Do you have a link or standalone testcase? Otherwise this will be hard to debug.
Comment 64•11 years ago
|
||
Sure, try this: <html> <head> <title>Firefox border-radius bug demo</title> <style type="text/css"> BUTTON { border-radius: 2em 2em 2em 2em; font-size: 110%; padding: 0.5em 1em; min-width: 7em; padding: 1px 1em; } </style> </head> <body> <button type="submit">Submit</button> </body> </html>
Comment 65•11 years ago
|
||
WFM on latest Firefox 23 through 25 on Mac with your code from comment 64. If you still experience issues, maybe on a specific platform only, please file a new bug (you should have done that anyway because you are having a specific issue – this is a tracking bug for several issues).
Comment 66•11 years ago
|
||
(In reply to Florian Bender from comment #65) > WFM on latest Firefox 23 through 25 on Mac with your code from comment 64. > > If you still experience issues, maybe on a specific platform only, please > file a new bug (you should have done that anyway because you are having a > specific issue – this is a tracking bug for several issues). OK, have just filed it as a new bug: https://bugzilla.mozilla.org/show_bug.cgi?id=901336 FYI, I'm using Windows 7 (64 bit).
Depends on: 901336
Comment 67•11 years ago
|
||
border-radius bugged on Firefox? -> http://grab.by/qEAS left: firefox aurora, right: chrome canary OS: Mac OS X 10.7.5 Firefox version: 26.0a2 (2013-09-24)
Comment 68•6 years ago
|
||
Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Updated•5 years ago
|
Summary: Tracking bug for remaining issues with CSS3 border-radius → [meta] Tracking bug for remaining issues with CSS3 border-radius
Updated•2 years ago
|
Severity: normal → S3
Updated•6 months ago
|
Attachment #9387505 -
Attachment is obsolete: true
You need to log in
before you can comment on or make changes to this bug.
Description
•