Re: [csswg-drafts] [css-shapes-1] basic-shape interpolation not interoperable with omitted positions. (#12339)

The CSS Working Group just discussed `[css-shapes-1] basic-shape interpolation not interoperable with omitted positions.`.

<details><summary>The full IRC log of that discussion</summary>
&lt;kbabbitt> emilio: main issue here is that we found an issue where depending on whether you omit position in circle or some other shapes<br>
&lt;kbabbitt> ... Blink does allow interpolating but Gecko and Webkit don't<br>
&lt;kbabbitt> ... trick here is that omitted position is special, different value at least for offset-path<br>
&lt;kbabbitt> ... in clip-path, omitted at center behaves the same<br>
&lt;kbabbitt> ... in clip-path if you omit position, it behaves same as at center<br>
&lt;kbabbitt> ... but in offset-path it doesn't<br>
&lt;kbabbitt> ... seems clear to me we shouldn't allow interpolating it in offset-path, doesn't make sense<br>
&lt;noamr> q+<br>
&lt;kbabbitt> ... for clip-path I could see an argument for allowing interpolation, but doesn't make sense to do different in different properties<br>
&lt;kbabbitt> ... woudl rather take webkit/firefox behavior<br>
&lt;kbabbitt> ... noamr mentioned expected to interpolate but no way to express mix<br>
&lt;kbabbitt> ... initial value of offset-path is computed at layout<br>
&lt;kbabbitt> astearns: sounds like a mistake<br>
&lt;kbabbitt> ... that offset-path is not expressible<br>
&lt;kbabbitt> emilio: probably<br>
&lt;kbabbitt> astearns: even if we do express it, it may not be interpolable<br>
&lt;astearns> ack noamr<br>
&lt;kbabbitt> noamr: from web dev perspective, I would rather have them interpolate than ? if we could<br>
&lt;kbabbitt> ... don't think difference between clip-path and offset-path is relevant<br>
&lt;kbabbitt> ... many people don't use offset-path, expect no position to behave as `at center`<br>
&lt;flackr> q+<br>
&lt;kbabbitt> ... can separately think about offset-path default position<br>
&lt;kbabbitt> ... start of path, how to represent that in layout terms and interpolate that<br>
&lt;kbabbitt> ... suggest that's separate, think about web devs first, say clip-path interpolates with center omitted<br>
&lt;ydaniv> +1 to noamr<br>
&lt;emilio> q+<br>
&lt;astearns> ack flackr<br>
&lt;kbabbitt> flackr: for interpolating other properties like transform<br>
&lt;kbabbitt> .. we try to coerce value at a given keyframe to be interpolable to neighboring keyframes<br>
&lt;kbabbitt> ... sometimes even turn into different format<br>
&lt;kbabbitt> ... intermediate can take on different shape just to be interpolable<br>
&lt;astearns> ack emilio<br>
&lt;kbabbitt> ... I think that's a good argument for trying to be interpolable here like noamr is asking for<br>
&lt;kbabbitt> emilio: main difference here is that interpolation of two transform lists is not property dependent<br>
&lt;kbabbitt> ... doesn't matter whether it's in a custom prop or what, they interpolate the same<br>
&lt;kbabbitt> ... this would add property dependency to interpolation which sounds a bit sketchy to me<br>
&lt;kbabbitt> ... don't think there's a precedent for that<br>
&lt;kbabbitt> ... I know we interpolate some values in contexts where we may not know which prop it applies to<br>
&lt;kbabbitt> ... agree in principle but would be good for someone in Blink to double check what is happening<br>
&lt;kbabbitt> ... feels weird to have property dependency without being explicit<br>
&lt;dbaron> I'm trying to look at the blink code now -- I don't see any explicit property dependency in what I think is the relevant code, but I do see code that passes around "HasExplicitCenter" values.<br>
&lt;kbabbitt> ... would be good to check what Blink is doing, is it what's being proposed here or do we need more tests for this<br>
&lt;dbaron> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/animation/basic_shape_interpolation_functions.cc<br>
&lt;dbaron> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/animation/css_basic_shape_interpolation_type.cc<br>
&lt;kbabbitt> ... other thing is, maybe we should make offset path default position at least representable<br>
&lt;kbabbitt> ... with auto or whatever<br>
&lt;kbabbitt> astearns: simon linked to another issue about unifying some grammars but it doesn't mention offset-path<br>
&lt;kbabbitt> ... likely need another issue about how to express default value for offset-path<br>
&lt;kbabbitt> ... omitted value<br>
&lt;kbabbitt> ... dbaron you are looking at code, do you have a conclusion?<br>
&lt;kbabbitt> dbaron: don't know the code well enough to come to a conclusion yet<br>
&lt;kbabbitt> noamr: seems like it animates to a discrete center<br>
&lt;kbabbitt> emilio: to be clear this is some of the view transitions demos that chrome devrel wrote depend on this behavior, that's how I found out about this<br>
&lt;kbabbitt> ... I can come back with test cases<br>
&lt;kbabbitt> astearns: we'll go back to the issue then, get some test cases for what interpolation of clip-path in Chrome is actually doing<br>
&lt;kbabbitt> ... need a separate issue on being able to express omitted value in offset-path<br>
&lt;kbabbitt> ... I'd like it if we could interpolate both cases but who knows if that's even possible<br>
&lt;kbabbitt> ... anything more for this issue?<br>
&lt;noamr> emilio, feel free to ping me about this outside of github<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12339#issuecomment-3357200370 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 1 October 2025 16:31:01 UTC