Open Bug 2045232 Opened 3 months ago Updated 3 months ago

farthest-corner and closest-corner parameters for ellipse() do no match the spec

Categories

(Core :: Layout: Floats, defect, P3)

Product:
Core
Component:
Layout: Floats
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox-esr115 --- unaffected
firefox-esr140 --- unaffected
firefox151 --- unaffected
firefox152 --- unaffected
firefox153 --- affected

People

(Reporter: Oriol, Unassigned)

References

(Blocks 1 open bug)

Details

Bug 2037673 implemented these in a way that doesn't match the spec.

https://drafts.csswg.org/css-images-3/#valdef-radial-extent-closest-corner

If the shape is an ellipse, the ending shape is given the same aspect-ratio it would have if closest-side were specified.

<!DOCTYPE html>
<style>
div { width: 100px; height: 50px; background: cyan; box-shadow: 0 0 0 50px; margin: 50px }
</style>
<div style="clip-path: ellipse(closest-corner closest-corner)"></div>
<div style="clip-path: ellipse(closest-side closest-side)"></div>

But in Firefox, they don't have the same aspect ratio:

  • closest-corner produces an ellipse with an aspect ratio of 1:1 (i.e. a circle).
  • closest-side produces an ellipse with an aspect ratio of 2:1
Blocks: interop-2026-shape
Flags: needinfo?(descalante)
Severity: -- → S3
Priority: -- → P3

Right, I wrote the patch for Bug 2037673 under the impression that since it's not really possible to always pass through both closest and farthest corner if the center of the ellipse was offset, then the rest of the spec was also in a bit of a weird state. Safari solved this by just using the distance to the closest/farthest corner and that seemed to make sense at the time but I do agree is pretty counter-intuitive from a user perspective. However, I think we should be able to always preserve the aspect ratio so we should implement that. We should probably also make a bug for WebKit and fix this test .

What do you think @boris, @emilio, @oriol?

Flags: needinfo?(descalante)

Yes, css-images-3 doesn't allow to combine the radial extent keywords with other values, to have different behaviors per axis. css-images-4 allows it, but doesn't explain the behavior.

So in general it's not clear how it should behave, https://github.com/w3c/csswg-drafts/issues/14010

But at least when both axes have the same corner value, then css-images-3 seems clear.

I didn't realize this has been implemented in other browsers, they all seem to use a ratio of 1:1

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