Open Bug 431176 (border-radius) Opened 16 years ago Updated 2 months ago

[meta] Tracking bug for remaining issues with CSS3 border-radius

Categories

(Core :: CSS Parsing and Computation, defect, P3)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect

Tracking

()

People

(Reporter: netrolller.3d, Unassigned)

References

(Depends on 9 open bugs, Blocks 1 open bug)

Details

(Keywords: meta)

Attachments

(1 file, 1 obsolete file)

Proposal for transition between borders of different thickness
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.
Dupe of bug 309905?
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
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 :-).
I can take this if Michael can't.
If you have the time for this, that would be nice.
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
grrr, assignment UI still doesn't work the way I think it does.
Assignee: nobody → zweinberg
Status: ASSIGNED → NEW
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.
(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.
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.
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.
Bruno: see figure 8 in http://dev.w3.org/csswg/css3-background/#the-border-radius
(you'll have to scroll down a bit).
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 :-)
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
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.
Depends on: 424423
(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.
Depends on: 450652
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.

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.
(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)
Depends on: 451134
By the way, the "2005 TR vs. 2008 ED" question is no longer relevant - implement the new 2008 TR.
Depends on: 458131
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
No longer depends on: 448193
(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
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
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
adding some deps:

 - bug 382721 (dots and dashes don't continue around corners) 
 - bug 459945 (stripe borders have the wrong curve in between stripes)
Depends on: 382721, 459945
There is actuaally one more problem, though no bug has been filed for it: there are no color transitions between different-colored borders.
Depends on: 483696
Thanks, I'd forgotten that one.  Filed bug 483696.
No longer depends on: 483696
Depends on: 483696
Depends on: 459144
Depends on: 500141
Depends on: 500734
Depends on: 466572
Depends on: 500804
Depends on: 474386
Depends on: 409547
-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).
Depends on: 485501
(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.)
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)
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
No longer depends on: 409547
I don't think bug 459144 would be very hard to fix.
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.
Keywords: qawanted
Whiteboard: qawanted → [parity-IE][parity-chrome]
And indeed, the spec is CR now. There is no reason to prefix it anymore.
The prefix should remain while there are still major bugs.  See comment 40.
Keywords: qawanted → meta
Whiteboard: [parity-IE][parity-chrome]
Depends on: 561746
No longer depends on: 561746
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.
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
(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.
(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.)
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.
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.
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.
(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.
Opera have bugs with border-radius too but they dont use vendor prefix.
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.
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
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.
Depends on: 596205
Depends on: 613905
Depends on: 803947
Bug 760358, Bug 652650 and maybe Bug 697645 should be added.
(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.
Depends on: 760358, 652650, 697645
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.
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
(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.
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>
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).
(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).
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)
Depends on: 947833
Depends on: 1218788
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
Summary: Tracking bug for remaining issues with CSS3 border-radius → [meta] Tracking bug for remaining issues with CSS3 border-radius
Severity: normal → S3
Attachment #9387505 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: