The diagrams on this page use SVG, which not all browsers support. The lower diagram also used HTML5 sliders and manipulates the image with Javascript. Whether all the parts will work on your browser is far from certain.
This diagram viewable only with an svg-enabled browser
Code to do these calculations demonstrated below
A.x = box.width - r_{h}
A.y = 0
B.x = box.width
B.y = r_{v}
Origin.x = A.x
Origin.y = B.y
C.x = Origin.x + r_{hinner}
C.y = Origin.y
D.x = Origin.x
D.y = Origin.y - r_{inner}
θ = (π/2)(w_{top}/(w_{top} + w_{right})) [see note 2]
E.x = Origin.x + sqrt(1/((r_{v}^{2}/r_{h}^{4})(tan^{2}θ) + 1/r_{h}^{2}) [see notes 3, 4]
E.y = Origin.y - sqrt(r_{v}^{2}(1 - E.x^{2}/r_{h}^{2})
F.x = Origin.x + sqrt(1/((r_{vinner}^{2}/r_{hinner}^{4})(tan^{2}θ) + 1/r_{hinner}^{2})
F.y = Origin.y - sqrt(r_{vinner}^{2}(1 - F.x^{2}/r_{hinner}^{2})
From the specification: 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. This is a place where showing the math would have made things a whole lot simpler for everyone. I took that phrase to mean the point on the curve where the tangent is normal to the angle, marked as point E above. The corresponding point on the inner edge of the border is point F. The only problem is, that's ugly.
Another possible interpretation is that they meant the points where a line of that slope that passes through the origin intersects the two curves (the green line on the diagram). The origin point would have to be adjusted for borders with thickness greater than the radius. The thing is, that can be pretty ugly, too.
I suspect the guys who came up with the windy version of how it should work never diagrammed it with any care. If they did, I'd love to see that diagram. In fact, they should put that diagram into the spec.
This diagram viewable only with an svg-enabled browser
Depending on your browser, you may see sliders to play with below.
border-top-right-radius.v: | 0 | |
border-top-right-radius.h: | 0 | |
border-top-width: | 0 | |
border-right-width: | 0 |
I would define the transition line as follows: A line with a slope proportional to the widths of the sides, normal to an ellipse between the midpoints of the inner and outer edges of the border. This was esaily the most aesthetic method for establishing the line that I could come up with. I'm still not entirely pleased aesthetiaclly with a couple of edge cases, but I don't think it's worth the effort to iron out every last detail.
It turned out to be easier to write code to calculate the points than to crunch the numbers for a specific case, and since I already had this nice little SVG image, I wrote Javascript to set the locations of the points on the graph.
Ho ho! Now that the image is driven by data, the next obvious step was to make sliders that changed the values of the inputs. Now it moves! My first venture into using Javascript to alter an image at runtime. Of course, being able to play with the sliders brought up all the boundary conditions, so I put them into the code as well. (There is one edge case my code still doesn't cover. Can you find it?)
This code snippet won't handle different border styles, but for solid borders it does better than any current browser. It would be very simple to implement most border styles (dashes would be tricky).
Why is it I enjoy fiddling with the sliders so much?
Copyright ⓒ 2010 Jerry Seeger
All Rights reserved until I get that creative commons thing figured out.