[motion-1] Add new tests for <basic-shape>

[danielsakhapov]

Test List

offset-path-shape-circle-001.html
offset-path-shape-circle-002.html
offset-path-shape-circle-003.html
offset-path-shape-circle-004.html
offset-path-shape-ellipse-001.html
offset-path-shape-ellipse-002.html
offset-path-shape-ellipse-003.html
offset-path-shape-ellipse-004.html
offset-path-shape-inset-001.html
offset-path-shape-inset-002.html
offset-path-shape-polygon-001.html
offset-path-shape-polygon-002.html
offset-path-shape-polygon-003.html
offset-path-shape-rect-001.html
offset-path-shape-rect-002.html
offset-path-shape-xywh-001.html
offset-path-shape-xywh-002.html

Rationale

There is only one test to cover the functionality of the basic-shapes for motion path. I propose to add these tests and delete offset-path-shape.html as it's incorrect (the sizes of the inset are resolved against its own size, not the reference box).

[danielsakhapov]

@BorisChiou @nmoucht FYI

[BorisChiou]

Gecko doesn't support basic shape for motion, so I'm OK with landing these tests (and may verify again when I work on the gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1598156)

[gsnedders]

In aggregate: this wpt.fyi query.

[foolip]

@gsnedders @nt1m can either of you get a position for WebKit on this?

[BorisChiou]

I just noticed these two tests:

1. offset-path-shape-circle-002.html
2. offset-path-shape-ellipse-002.html

Their expectations (i.e. xxx-ref.html) seem incorrect to me.

Per css-shape spec (https://drafts.csswg.org/css-shapes-1/#typedef-shape-radius), for <shape-radius>:

Defines a radius for a circle or ellipse. If omitted it defaults to closest-side.

So they are equal to circle(closest-side) and ellipse(closest-side). The closest-side in the test for circle() is 200px, so the translate() in its ref file is something like translate(450px, 150px), right?

Also, I noticed there are some floating-point numbers used in the xxx-ref files, e.g. offset-path-shape-ellipse-003-ref.html. I may update thest tests to avoid using so many floating-point numbers in the xxx-ref files. Also, I may add more fuzzy expectations in these tests (for circle() and ellipse()) for Gecko.

(Note: I expect the fuzzy happens because Gecko uses a different way to handle sub-pixel anti-alias, and the arc calculation makes the angles of the tangent vectors have some minor differences. However, the visual results are almost identical.)

[danielsakhapov]

@BorisChiou

Hi! Thanks for your comment!

1. The nuance with this test is here:

If circle() or ellipse() is used, and an explicit center position is not given, they default to using the offset starting position, rather than their standard default.

That's why the box ends up at the containing block's top left corner with zero radius, only moved by -50px to match it's center.

2. If you could update tests to have integer numbers, it would be great! I just couldn't find anything integer to test rotation on the circle and ellipse.

3. I'm absolutely fine with fuzziness in the motion path case!

[BorisChiou]

I deleted my previous comment because now I understand the reason. For circle(), the default offset-position makes the center of the circle be top left, so the radius, closest-side, is 0px. That's why the final translate is translate(-50px, -50px).

[tabatkins]

No, not quite. It makes it be the top left of the transformed element (its pre-transform position). Now, in this case, that happens to also be the top left of the containing block, because that's just how the element is positioned. Then we resolve closest-side against the containing block and get a 0 radius.

If the square had a margin on it, or the container had padding, or anything to not make those two corners coincident, then we'd get a non-zero radius out of it.

(And btw, I had some pending edits from w3c/fxtf-drafts#504 that I've just applied, so it would be good to get some tests for that as well - offset-position can now be normal, which means you use the normal defaulting rules for an omitted position as specified by the Shapes spec.)

[BorisChiou]

Thanks for the "NOTE" to explain the definition of the box for offset-position:auto in the spec. :)

[tabatkins]

If it makes you feel better, I actually wrote that text before seeing your comment; it just felt like something that should be made more explicit. ^_^

[nmoucht]

@gsnedders @nt1m can either of you get a position for WebKit on this?

I don't have any objections to adding these tests.

[danielsakhapov]

thanks all, closing the issue

[foolip]

I have labeled the 17 issues in web-platform-tests/wpt-metadata#4313. Note that offset-path-shape-circle-005.html and offset-path-shape-ellipse-005.html were not labeled, because they weren't discussed above.

[BorisChiou]

BTW, I just noticed offset-path-shape-xywh-002.html may be incorrect. It seems Blink uses the height of its reference box to resolve the percentage value of the width of the transformed box:
https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:third_party/blink/renderer/core/style/basic_shapes.cc;l=253;drc=80833aef0b4fff4978b49865bb95a7497f200c71.

Therefore, I'm updating this test file in Gecko's bug right now (https://bugzilla.mozilla.org/show_bug.cgi?id=1786160).