Initial value for the 'rx' and 'ry' properties

[fsoder]

The initial value for the 'rx' and 'ry' properties are currently specified [1] as being '0'. This however means that it isn't possible to distinguish 'not specified', which is referred to in [2]:

The values used for the x- and y-axis rounded corner radii are determined implicitly if the rx or ry attributes (or both) are not specified, or are specified but with invalid values.

and

...if a properly specified value is provided for rx, but not for ry, then set both rx and ry to the value of rx.

et.c.

(This currently causes a bug in Blink, ref [3].)

[1] https://svgwg.org/svg2-draft/geometry.html#RX
[2] https://svgwg.org/svg2-draft/shapes.html#RectElement
[3] https://bugs.chromium.org/p/chromium/issues/detail?id=576811

[AmeliaBR]

Thanks for catching this. Yes, an auto initial value is required for ry in rectangles. Or perhaps we want a more meaningful keyword like match-rx, circular, or symmetrical?

A further question is do we want to assign this default only to rect elements with a rule in the default stylesheet, or do we want to extend the same behavior to <ellipse>? That would mean that an ellipse with only rx specified is a circle of that radius. Note that this would be a different result than setting rx and ry to the same explicit value, because of the way percentages are interpretted.

Currently, an ellipse would not be drawn at all if the ry attribute is omitted, so although this would be a breaking change, it would only change things that are already broken.

And if we're going to make it possible to declare an ellipse that is actually a circle controlled by a single radius, it would be nice to make <circle> work in a consistent fashion. Maybe make r a proper shorthand for rx and ry. But again, the behavior of percentages complicates things: the computed value of a percentage for r is a geometric average of the computed values for the same percentage for rx and ry. A circle with percentage radius is therefore different again from an ellipse in which ry is set to match the computed value of rx.

(A demo for anyone confused about the current interpretation of percentages in all these cases. Note that the circle is being clipped to the SVG dimensions. Also note that the percentages in the rectangle's radii attributes are relative to the coordinate system (SVG) dimensions, not to the rectangles width and height, which just happens to be the same for clarity.)

[tabatkins]

Yes, an auto initial value is required for ry in rectangles. Or perhaps we want a more meaningful keyword like match-rx, circular, or symmetrical?

I suggest just using auto.

That would mean that an ellipse with only rx specified is a circle of that radius. Note that this would be a different result than setting rx and ry to the same explicit value, because of the way percentages are interpretted.

Currently, an ellipse would not be drawn at all if the ry attribute is omitted, so although this would be a breaking change, it would only change things that are already broken.

We should go ahead and align the behavior; the difference isn't interesting/intentional.

Why do you think it would cause a circle? It should just copy the value over as it is, so %s stay as %s, causing an ellipse with the same aspect ratio as the container.

But again, the behavior of percentages complicates things: the computed value of a percentage for r is a geometric average of the computed values for the same percentage for rx and ry. A circle with percentage radius is therefore different again from an ellipse in which ry is set to match the computed value of rx.

Right, so unfortunately we cannot make r a shorthand for rx and ry, at least not without a third longhand dictating how to interpret a percentage. That's not a great idea, tho, as it would need a default value favoring either circles or ellipses, and authors would always have to set it to the non-default value for the other shape.

Given the "ry:auto takes its value from rx" behavior, tho, making r a shorthand wouldn't add any convenience anyway, so there's no real reason to do it.

(Or, hmm, we could do it automatically by having the third property default to ellipse, and a single value in r set it to circle instead. But this is getting to be too much magic; much simpler imo to just say that r is for geometry:circle and rx/ry are for geometry: ellipse.)

[AmeliaBR]

Why do you think it would cause a circle? It should just copy the value over as it is, so %s stay as %s, causing an ellipse with the same aspect ratio as the container.

That's not how it works for rounded rectangles (see my linked demo). The computed value is duplicated over, not the percentage, so you always have a circular arc.

But as you say, it is only a problem if we want to define this all in terms of shorthand. Just having ry: auto mean "create a circular arc defined by the rx radius" still works fine.

[tabatkins]

Ahhhh, indeed. My tests were showing "50%" on <rect> making it an ellipse, but that's due to rounded corners getting clamped to half of the width/height. (That's different from how border-radius works.)

So yeah, ry:auto sticking around until used-value time and then just meaning the same length works.

[AmeliaBR]

Spec text: https://svgwg.org/svg2-draft/geometry.html#RY

[BigBadaboom]

Is the value "auto" also supposed be listed in the "Value" field of the info box?

[fsoder]

I think that the steps (after the fourth paragraph) at https://svgwg.org/svg2-draft/shapes.html#RectElement could use some touchup too.

[AmeliaBR]

Thanks @BigBadaboom and @fsoder. Should have been looking at both sections together.

I'm not sure why I thought that only ry would match rx and not vice versa. Looks like both need to have an auto value by default, and then we need to say that if both have a computed value of auto, the used value is 0. We also need to clarify that the used value in a rectangle is never more than 50% of the width/height, as applicable. Most of the rest of that step-by-step list (under <rect>) can then be collapsed.

[AmeliaBR]

Updated https://svgwg.org/svg2-draft/geometry.html#RX to include both auto cases (and to ensure that auto is listed as a valid value for both properties).

Needs some markup cleanup to get property names/values highlighted consistently.

Still need to clean up the corresponding sections in the Basic Shapes chapter.

[AmeliaBR]

The required edits to basic shapes were merged into master via 1947fd3.