RE: Idea : replacement for border-radius, a more complete corner styling property.

Yes, Brian, the rendering looks good and is what I was visualizing.

To Jerome:

First off, it’s “border-radius-SHAPE,” not “border-radius-STYLE.” The latter would have an entirely different purpose, more in keeping with what “border-style” does (“solid”, “double”, “dashed”, “dotted”, “inset”, “outset”, “groove”, “ridge”, etc., applied individually or to all four corner portions as specified in the relevant “border-radius” and shaped by “border-radius-shape”).

Secondly, using a negative value has a different purpose. “border-radius-shape: concave” is a specific border rounding shape. The technical implementation algorithm aspects would be something like this:

For any border-radius-shape, create circles or ellipses of the specified radius or radii, near the specified corners of the box. For most shapes, the centers of the ellipses (including circles, a specialized form of ellipse) would coincide with where the corner of the box would otherwise be. The portions of the normal straight box border which overlap this circle are not rendered by the normal box drawing algorithm (or else are “clipped” or “cut out”), but by the box radius drawing algorithm as follows:

The current standard is “convex” repositions (shifts) the ellipses so that their outer quadrant circumferences are tangent to the box shape (or, if you prefer, so that the bounding box of the ellipse exactly overlaps the actual box sides and corners). The algorithm traces the outer quadrant of the ellipse starting with the point tangent to one box side of that corner, and ending with the point tangent to the other box side of that corner. This produces the traditional “rounded corners” effect. This would be the default.

The “concave” shape would (A) leave the ellipse centered on the box corner, and (B) reverse which portion of the ellipse is traced: instead of the outer quadrant, it traces the quadrant opposite that, the only quadrant that now intersects the box itself, cutting out a convex quarter of a circle or ellipse from the corner.

The “beveled” or “angled” or “diagonal” shape also leaves the centers coincident with the corners, but instead of tracing any portion of the circumference, it instead traces the diagonal diameter, with the endpoints at the tangent points.

The “box-convex” and “box-concave” do what “convex” and “concave” normally do, but trace the ellipse’s bounding box instead of its circumference. Since “box-convex”, like “convex”, shifts the ellipse centers inward to cause it to exactly overlap the box itself, this normally would have no visual effect, but in conjunction with “box-radius-style” (and, I just thought of, “box-radius-color”), it could apply a separate style and/or color to the corner.

For any of you who have used or have access to Adobe InDesign, check out its “Rounded Corners” effect for examples of all of the above, plus an additional shape that I don’t think that CSS needs to bother with (“fancy” which does a sort of squared Greek loop effect).

It also occurs to me that two more shapes could be easily implemented from the two “convex” variants that do NOT reposition their ellipses, but leave them centered on the box corners. Instead, they would trace the outer THREE quadrants (¾ of the circumference or bounding box, respectively). In effect, these would do exactly what the respective “concave” variants do, but trace the three quadrants that “[box-]concave” would NOT trace, and NOT trace the one box-overlapping quadrant that “[box-]concave” WOULD trace. I’m not sure what to call these: “outer-convex” and “box-outer-convex”? Also, since both of these would cause the final box rendering to exceed its box border size and extend into or even past the box margin area, these two may violate CSS positioning philosophy. But they would enable additional cool box shapes with simple and backward-compatible CSS extensions.

On border-radius values:

At present, these can be specified as a positive number of pixels or other simple units. When set as absolute units (e.g. “px”), specifying a single border-radius value for a corner always produces circular rounding (or other shaped effect if the above is implemented).

Percentage should be allowed here, just as it is for almost anything else that accepts a sizing parameter. The percent value would be the percent of the total box width or height, including border, of the box as it would be without the rounding effect. This would also have the side effect of, for a non-square rectangular box (taller than wide or wider than tall), produce NON-CIRCULAR, ELLIPTICAL rounding from a SINGLE border-radius value!

So, for instance, simply doing “border-radius: 50%;” and leaving everything else at default (including letting “border-radius-shape” default to the usual “convex”) automatically causes the box to render as a CIRCLE (if the box were square) or ELLIPSE (if the box were non-square)! No need to try to calculate the exact pixel value you need!

For all shapes, the value specified should be clipped to 50% if it exceeds 50% of the box size, regardless of whether it’s specified in percentage or absolute units. For instance, if a box width (counting its border width) were 200 pixels wide and 100 pixels tall, a convex border-radius of 75px would produce rounding that is equivalent to 75px/50px, because 50% of 100px is 50px, and you couldn’t round the 100 pixels more than that. Some browsers (at least older versions) simply ignored any border-radius that exceeded the maximum value, leaving that corner entirely unrounded. In my opinion, this is improper. The proper response to being told to round a corner more than is physically possible to do is to round it as much as is physically possible to do, not to simply not round it at all.


-----Original Message-----
From: Jerome Leclanche [mailto:adys.wh@gmail.com] 
Sent: Tuesday, August 02, 2011 11:52 PM
To: Brad Kemper
Cc: Brian Manthos; Joel_MMCC; www-style@w3.org; "François REMY (fremycompany_pub@yahoo.fr)"; fantasai
Subject: Re: Idea : replacement for border-radius, a more complete corner styling property.

This may have been mentioned before, but I don't understand the need
for border-radius-style: concave. Wouldn't border-radius: -70px
(which, afaik, currently is the same as 0) fit for that behaviour? Or
are there other border-radius-styles?

On Wed, Aug 3, 2011 at 5:25 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
> On Aug 2, 2011, at 7:01 PM, Brian Manthos <brianman@microsoft.com> wrote:
>
>> Joel_MMCC:
>>> • “concave” (my unique one that has no equivalent in François’s proposal:
>>> rounded, but cut INTO the box corners, like the corners of old-fashioned
>>> photographs, ticket stubs, etc. — sort of like his “square-cutted,” but rounded
>>> instead of square)
>>
>> Suppose you had:
>>
>> (1)
>> div {
>>   width: 150px;
>>   height: 50px;
>>   border-color: red blue green black;
>>   border-radius: 25px;
>>   border-radius-style: concave;
>>   border-width: 50px;
>>   border-style: solid;
>> }
>>
>> (2)
>> div {
>>   width: 240px;
>>   height: 140px;
>>   border-color: red blue green black;
>>   border-radius: 70px;
>>   border-radius-style: concave;
>>   border-width: 5x;
>>   border-style: solid;
>> }
>>
>> Would you want it to look like the attached renderings?
>>
>> More specifically, it wasn't explicit in your description whether you want the inner edge of the border to have an expanded radius (like the opposite of what happens for the current border-radius inner edge behavior).
>> <JoelConcave1.png>
>> <JoelConcave2.png>
>
> If he doesn't say, I will: Yes. The rendering looks good.
>
> I wonder if that should mean that border-radius:50% should run into the "doesn't fit, so scale corners uniformly" rule, so that there was always room for a complete line thickness  where two corner shapes meet (or should two curves not be allowed to even overlap, and thus always be separated by two line thicknesses), or could two curves come together in a point without any border thickness extending outside that point? Something to consider.
>
>

Jerome Leclanche

Received on Wednesday, 31 August 2011 17:11:51 UTC