Bug 30038
| Summary: | border-radius renders incorrectly when border widths do not match | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Jerry Seeger <vikingjs> |
| Component: | CSS | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | mitz |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Mac (Intel) | ||
| OS: | OS X 10.6 | ||
| URL: | http://muddledramblings.com/table-of-css3-border-radius-compliance | ||
Jerry Seeger
rendering of border is incorrect (and unsightly) when the widths of the borders to be joined do not match.
Two cases come up with incorrect results:
<code>border-left: solid 4px;
border-top: solid 30px;
border-top-left-radius:20px;</code>
When the radius is less than the width of the wider border, there is a notch in the rendered result.
<code>border-left: solid 4px;
border-top: solid 15px;
border-top-left-radius:30px;</code>
When the radius is between the two widths, the curve does not taper correctly. the CSS3 proposal only states that the transition should be 'smooth', but doesn't specify an algorithm. The illustration in the spec uses a circular inner curve, mozilla uses an elliptical curve.
Both these cases are visible in the table at the above URL. I could not find a test case in the latest trunk download that addressed unequal border widths.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Jerry Seeger
It looks like solid borders are done with strokes (and there's a bit of a hack to get them to match the clip area). For this bug, the corners are going to have to be done with fills. Probably simplest to draw the entire border with fills, especially since all the key points are already defined.
Worth noting that the troubles with making the clip and the border match could also be solved by using paths and fills. The same math cold be used to calculate the edge of the fill and the clip.
mitz
*** This bug has been marked as a duplicate of bug 17468 ***