CornerRadius border radius value semantic and ergonomic improvements#25050
CornerRadius border radius value semantic and ergonomic improvements#25050ickshonpe wants to merge 4 commits into
CornerRadius border radius value semantic and ergonomic improvements#25050Conversation
`CornerRadius` has different semantics to `Val2`: - If one field is auto, the resolved radius will be circular with the radius clamped to max half of the min of the node's width or height. - If either field is zero or both are auto, the node will have square corners.
|
Your PR caused a change in the graphical output of an example or rendering test. This might be intentional, but it could also mean that something broke! If it's expected, please add the M-Deliberate-Rendering-Change label. If this change seems unrelated to your PR, you can consider updating your PR to target the latest main branch, either by rebasing or merging main into it. |
1 similar comment
|
Your PR caused a change in the graphical output of an example or rendering test. This might be intentional, but it could also mean that something broke! If it's expected, please add the M-Deliberate-Rendering-Change label. If this change seems unrelated to your PR, you can consider updating your PR to target the latest main branch, either by rebasing or merging main into it. |
Objective
The elliptical border-radius PR was merged with a slightly half baked API.
In particular, a corner given a single radius value should be circular or square. For example, with:
it should clamp the radius on both axes to the min half size (50) so we get circular corners, but on main atm you get an elliptical (100, 50) radius corner.
Solution
Val2has the wrong semantics. Added a new structCornerRadius { x: Val, y: Val }.CornerRadiuscreated from a singleval: Valis mapped toCornerRadius { x: val, y: Val::Auto }.Still needs a bit more bikeshedding and some additional docs.
Testing
There is a new test and an extra example case in the elliptical radius UI testbed.