395674 - fix -moz-border-radius to match new CSS WG decisions

Status: RESOLVED DUPLICATE of bug 431176

(Core :: Web Painting, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So at our meeting today, the CSS Working Group agreed to change border-radius in the following ways that affect Mozilla:

 * the curvature of the inner edge of the border should be the 90 degrees of circular or elliptical curvature such that the center of the circle or ellipse is the same as the center of the circle or ellipse for the outer border and the circle is tangent to the inner borders at the correct border widths for each side of the corner.  If this point is inside or on either of the inner border edges (straight), then there's no curvature at all (just a corner).

 * the bevel between the border colors / styles should connect the points on the **curvature** of the inner and outer border edges such that the share of angle given to each side is proportional to the thickness of the border on that side.  This has the nice properties that:
   * it has continuity for border radius approaching 0 (since it's the angle on the curved segment only)
   * it has the same effect as standard beveling when both borders are the same thickness
   * it means that a border-radius connecting a real side to a 0-width side uses only the color/style from the real side

(We also came to an agreement about how to handle radii where the curved segments intersect, I think, although I'm not sure if we actually finalized it.  I should look at the minutes to see what that was.  And we also agreed that the border-radius shorthand should work like Mozilla's rather than like the current draft in the simple case, with some extra syntax needed for elliptical corners.)

Comment 1

[Stuart Parmenter]

we should probably just implement border-radius rather than changing -moz-border-radius

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I'm not sure I understand "If this point is inside or on either of the inner border edges (straight), then there's no curvature at all (just a corner)."... though maybe when you're back we can just grab a whiteboard, it seems like this all would be much easier to explain with a few graphs. :)

The two issues I sent mail about to www-style were:

1) What should happen if adjacent borders are a) different widths; b) different styles.  It sounds like the second change describes this, though again, I'm not sure I understand fully.

2) what should happen to the border rendering when the border-radius is bigger than half of the size of the content -- for example, should a <div style="width: 100px; height: 100px; border: 5px solid blue; border-radius: 5000px 5000px;"></div> be invalid, or should it approach a diamond shape?  I'm not sure if the first change describes this case.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The two bullets here are really only about (1).  (2) is in the "we also discussed, but I need to look at the minutes to figure out what, if anything, we resolved".

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

And we've already changed -moz-border-radius a bit with the border rewrite, and we technically shouldn't be implementing it as border-radius until the draft is in CR.  And I really don't think we want to carry 2 implementations plus the storage for which to use around.

Comment 5

[Rick]

re: Comment #1
"we should probably just implement border-radius rather than changing
-moz-border-radius"

Probably???!!!!!   PROBABLY????????????!!!!!!??????????

How long have yall had -moz-border-radius working?  Two years??   Three???

Just Move The D*** Code And Get Border-radius working.

Re: Comment #4

No, you don't want to have two implementations.  Just have one: border-radius.  If you feel the need to wait for CR status then take out ALL of your CSS 2.1 support and any other pieces of CSS 3 you've added (like hsl).

Jeeezzz.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #5)
> No, you don't want to have two implementations.  Just have one: border-radius. 
> If you feel the need to wait for CR status then take out ALL of your CSS 2.1
> support and any other pieces of CSS 3 you've added (like hsl).

Both of those have been in CR.

In any case, if you wanted a serious answer, you should have been less rude.  Please don't comment further on this bug.

Comment 7

[Emil Ivanov]

Attachment: testcase

Comment 8

[Emil Ivanov]

Comment on attachment 404341 [details]
testcase

Oops wrong bug sorry...

Comment 9

[iiridayn]

(In reply to comment #4)
> And we've already changed -moz-border-radius a bit with the border rewrite, and
> we technically shouldn't be implementing it as border-radius until the draft is
> in CR.  And I really don't think we want to carry 2 implementations plus the
> storage for which to use around.

It's in CR, as  of 17 Dec 2009 (http://www.w3.org/TR/2009/CR-css3-background-20091217/#the-border-radius).  I respectfully request that it be implemented as border-radius.  (Or if nothing else, not throwing an error of it being an unknown property).  Best might be making one a stub that calls the other - if the code is written such to support that.  That way it's DRY, but supports both properties - depending on how the code is structured internally.

Comment 10

[Zack Weinberg (:zwol)]

I do not want to change the name while we still implement notably different semantics than are specified.

Comment 11

[Zack Weinberg (:zwol)]

Let me unpack that a little.  I believe everything that dbaron described in comment 0 has been implemented as of Firefox 3.6.  However, there are still 20 bugs that block bug 431176, which is the tracker for "remaining issues with border-radius".  Of that set, I think that we should definitely fix bug 485501 (clip images to the border-radius) and bug 471643 (vertical percentages should be relative to box height, not width) before we start accepting unprefixed border-radius properties.  We should maybe also fix bug 459144 (clip *all* content to the curve when overflow!=visible).  The other bugs are less important IMO, and some of them need QA effort to determine if they're even still valid, but if we changed the names before we fixed the percentages and the clipping, we wouldn't be living up to designers' expectations that CSS properties work as specified or not at all.

I think the right thing to do with this bug at this point is collapse it into 431176.