You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thinking about this has sent me into a rabbit hole. Two issues:
how do we name this option (maybe "high-end radius—rh"—knowing that high will be bottom for negative values, right for horizontal bars and left for horizontal-negative)?
instead of a svg:rect we'll now have a generic svg:path. We can do one that just implements rh (if not nullish[1]), and keep it at this.
But there might be future use cases (some we already have in mind) where the element we create is completely different: what if, for example, if we want bars that follow a radial coordinate system (#133). (Or even, marks that are rendered with the same visual logic but using canvas instead of SVG…)
So, while we can implement this with a simple test like (rh != null ? "rect" : "path") (and maybe we should, I can put up a PR for this anyway), it's also tempting to take this as an opportunity to think more globally about how we'd want to be able to pass new "visual materializers" to marks.
[1] I'd want an explicit rh: 0 to opt-in to a svg:path, in order to make it possible to transition from rh=0 to rh=5 without discontinuity.
Hmm, one possibility is an ry2 option that rounds the corners corresponding to the y2 edge. Then you could have similar options ry1, rx1, rx2 for the other sides — but you’d have to define which side takes precedence since the sides would compete for the corners.
Another possibility is separate radii for each corner, like CSS does for border-radius (which also supports elliptical corners!).
As originally suggested in #1201, this is a common request, and the workaround isn’t always feasible (for example with diverging bars).
The text was updated successfully, but these errors were encountered: