Compute values of basic shape rect() and xywh() as the equivalent inset()

[darinadler]

534a722

Compute values of basic shape rect() and xywh() as the equivalent inset()
https://bugs.webkit.org/show_bug.cgi?id=266513
rdar://problem/119739406

Reviewed by Tim Nguyen.

CSS Shapes called for this behavior but we did not implement it yet.

* LayoutTests/imported/w3c/web-platform-tests/css/css-masking/animations/clip-path-interpolation-xywh-rect-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/css/css-masking/parsing/clip-path-computed-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/css/motion/animation/offset-path-interpolation-006-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/css/motion/parsing/offset-path-computed-expected.txt:
More PASS, less FAIL.

* Source/WebCore/css/BasicShapeFunctions.cpp:
(WebCore::valueForBasicShape): Added code that computes the equivalent inset as specified.
Use the CSSCalcValue machinery as needed.

Canonical link: https://commits.webkit.org/272180@main

977dfbc

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
✅ 🧪 bindings	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	✅ 🧪 wpe-wk2
✅ 🧪 webkitperl	✅ 🧪 ios-wk2	✅ 🧪 api-mac	✅ 🧪 api-wpe
	✅ 🧪 ios-wk2-wpt	✅ 🧪 mac-wk1	✅ 🛠 gtk
	✅ 🧪 api-ios	✅ 🧪 mac-wk2	✅ 🧪 gtk-wk2
	✅ 🛠 tv	✅ 🧪 mac-AS-debug-wk2	✅ 🧪 api-gtk
	✅ 🛠 tv-sim
✅ 🛠 🧪 merge	✅ 🛠 watch
	✅ 🛠 watch-sim

[webkit-early-warning-system]

EWS run on current version of this PR (hash 977dfbc)

Details

Misc	iOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
✅ 🧪 bindings	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	✅ 🧪 wpe-wk2
✅ 🧪 webkitperl	✅ 🧪 ios-wk2	✅ 🧪 api-mac	✅ 🧪 api-wpe
	✅ 🧪 ios-wk2-wpt	✅ 🧪 mac-wk1	✅ 🛠 gtk
	✅ 🧪 api-ios	✅ 🧪 mac-wk2	✅ 🧪 gtk-wk2
	✅ 🛠 tv	✅ 🧪 mac-AS-debug-wk2	✅ 🧪 api-gtk
	✅ 🛠 tv-sim
✅ 🛠 🧪 merge	✅ 🛠 watch
	✅ 🛠 watch-sim

[nt1m]

Looks good aside from one comment, thanks!

[nt1m]

From https://drafts.csswg.org/css-shapes-1/#basic-shape-computed-values :

An auto value makes the edge of the box coincide with the corresponding edge of the reference box: it’s equivalent to 0% as the first (top) or fourth (left) value, and equivalent to 100% as the second (right) or third (bottom) value.

Is this conversion correct? Maybe converting to 100% in the relevant cases would fix the interpolation tests?

[darinadler]

It’s correct. There are no 100 cases, because all the auto are in rect and we are always converting to inset and so it’s always 0 once it’s a value in the inset. Earlier ways I wrote the code had some 100 cases because I wrote it based on the above text, but as I refined and refactored the code, it led to it just being this. I’ve looked at remaining failing interpolation tests and the issues are the interpolation not the values.

[darinadler]

Oh, actually, I thought of another way to explain the refactoring. Rather than have a separate case of 100 in here, I put a special case for auto into createReflectedValue. If I had not done that, then I would have had to pass in a value of 0 or 100, and it would have computed 100% - 100% and ended up 0% anyway.

[webkit-ews-buildbot]

Safe-Merge-Queue: Build #6396.

[webkit-commit-queue]

Committed 272180@main (534a722): https://commits.webkit.org/272180@main

Reviewed commits have been landed. Closing PR #21903 and removing active labels.