Closed Bug 1786160 Opened 2 years ago Closed 8 months ago

[css-shapes-1] Implement xywh() function

Categories

(Core :: CSS Parsing and Computation, enhancement)

enhancement

Tracking

()

RESOLVED FIXED
117 Branch
Tracking Status
firefox117 --- fixed

People

(Reporter: sebo, Assigned: boris)

References

(Blocks 3 open bugs, )

Details

(Keywords: dev-doc-complete)

Attachments

(5 files)

The CSS Shapes 1 specification defines an xywh() function to create a rectangular shape.

This bug is meant to implement that function.

Sebastian

We may have to support this as well for motion-1.

Blocks: motion-1
Severity: -- → S3
Assignee: nobody → boris.chiou

(In reply to Boris Chiou [:boris] from comment #2)

We may have to support this as well for motion-1.

In particular, this is required for these WPTs which contribute to the interop-2023 "Motion Path" focus area:
https://wpt.fyi/results/css/motion/offset-path-shape-xywh-001.html
https://wpt.fyi/results/css/motion/offset-path-shape-xywh-002.html

Both of those tests use offset-path: xywh(...).

And it seems like there is no test case of rect() and xywh() for clip-path in WPT. (But there are tests of shape() for clip-path in WPT.) So I will add some tests of xywh() for clip-path as well in this bug.

Also, add layout.css.basic-shape-xywh.enabled and enable it on Nightly

And rename some functions, e.g. BuildInsetPath as BuildRectPath and
ComputeInsetRadii as ComputeRectRadii, because we would like to use it for
inset()/xywh()/rect(). All of them define the similar rectangles.

Also, tweak the tests:

  1. tweak offset-path-shape-xywh-001.html to avoid the element just at
    the bottom-right corner of path because there is no tangent angle at this
    point. Its direction angle could be 90deg or 180deg, depends on the
    implementation.
  2. tweak offset-path-shape-xywh-002.html and
    offset-path-shape-xywh-002-ref.html together because it seems the
    original ref file is incorrect. The test was added by Blink and the
    implementation of xywh() in Blink uses the height of the reference box to
    resolve the precentage value of the width of the transformed box.
    It doesn't make sense because we should use the width of the reference box
    to resolve it. So tweak the test and its reference file together
    based on Gecko's result.

The fuzzy in the test happens on the round because we use the different way
to draw the round of clip-path (compared to border-radius property) in
the render backend, so there are some tiny differences.

We would like to use these function for all rectangular shape, i.e.
inset()/xywh()/rect(). So rename them to avoid confusion.

No behavior change.

Pushed by bchiou@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/66865edf765b
Support xywh() in style. r=emilio
https://hg.mozilla.org/integration/autoland/rev/7bb336a7878e
Rename inset as rect in ShapeUtils. r=emilio
https://hg.mozilla.org/integration/autoland/rev/fb419d8b4ca6
Support xywh() for offset-path. r=emilio
https://hg.mozilla.org/integration/autoland/rev/0aa826684137
Support xywh() for clip-path. r=emilio
https://hg.mozilla.org/integration/autoland/rev/98306fe9e124
Add test to make sure the animations of offset-path:xywh() run on the compositor. r=hiro
Blocks: 1842277
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/40925 for changes under testing/web-platform/tests
Upstream PR merged by moz-wptsync-bot

MDN doc updates for this feature can be tracked via this issue: https://github.com/mdn/content/issues/28286 (in review).
Thank you for your help, Boris!

Blocks: 1868722
You need to log in before you can comment on or make changes to this bug.