- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 01 Oct 2025 16:31:00 +0000
- To: public-css-archive@w3.org
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> <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> <kbabbitt> ... Blink does allow interpolating but Gecko and Webkit don't<br> <kbabbitt> ... trick here is that omitted position is special, different value at least for offset-path<br> <kbabbitt> ... in clip-path, omitted at center behaves the same<br> <kbabbitt> ... in clip-path if you omit position, it behaves same as at center<br> <kbabbitt> ... but in offset-path it doesn't<br> <kbabbitt> ... seems clear to me we shouldn't allow interpolating it in offset-path, doesn't make sense<br> <noamr> q+<br> <kbabbitt> ... for clip-path I could see an argument for allowing interpolation, but doesn't make sense to do different in different properties<br> <kbabbitt> ... woudl rather take webkit/firefox behavior<br> <kbabbitt> ... noamr mentioned expected to interpolate but no way to express mix<br> <kbabbitt> ... initial value of offset-path is computed at layout<br> <kbabbitt> astearns: sounds like a mistake<br> <kbabbitt> ... that offset-path is not expressible<br> <kbabbitt> emilio: probably<br> <kbabbitt> astearns: even if we do express it, it may not be interpolable<br> <astearns> ack noamr<br> <kbabbitt> noamr: from web dev perspective, I would rather have them interpolate than ? if we could<br> <kbabbitt> ... don't think difference between clip-path and offset-path is relevant<br> <kbabbitt> ... many people don't use offset-path, expect no position to behave as `at center`<br> <flackr> q+<br> <kbabbitt> ... can separately think about offset-path default position<br> <kbabbitt> ... start of path, how to represent that in layout terms and interpolate that<br> <kbabbitt> ... suggest that's separate, think about web devs first, say clip-path interpolates with center omitted<br> <ydaniv> +1 to noamr<br> <emilio> q+<br> <astearns> ack flackr<br> <kbabbitt> flackr: for interpolating other properties like transform<br> <kbabbitt> .. we try to coerce value at a given keyframe to be interpolable to neighboring keyframes<br> <kbabbitt> ... sometimes even turn into different format<br> <kbabbitt> ... intermediate can take on different shape just to be interpolable<br> <astearns> ack emilio<br> <kbabbitt> ... I think that's a good argument for trying to be interpolable here like noamr is asking for<br> <kbabbitt> emilio: main difference here is that interpolation of two transform lists is not property dependent<br> <kbabbitt> ... doesn't matter whether it's in a custom prop or what, they interpolate the same<br> <kbabbitt> ... this would add property dependency to interpolation which sounds a bit sketchy to me<br> <kbabbitt> ... don't think there's a precedent for that<br> <kbabbitt> ... I know we interpolate some values in contexts where we may not know which prop it applies to<br> <kbabbitt> ... agree in principle but would be good for someone in Blink to double check what is happening<br> <kbabbitt> ... feels weird to have property dependency without being explicit<br> <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> <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> <dbaron> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/animation/basic_shape_interpolation_functions.cc<br> <dbaron> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/animation/css_basic_shape_interpolation_type.cc<br> <kbabbitt> ... other thing is, maybe we should make offset path default position at least representable<br> <kbabbitt> ... with auto or whatever<br> <kbabbitt> astearns: simon linked to another issue about unifying some grammars but it doesn't mention offset-path<br> <kbabbitt> ... likely need another issue about how to express default value for offset-path<br> <kbabbitt> ... omitted value<br> <kbabbitt> ... dbaron you are looking at code, do you have a conclusion?<br> <kbabbitt> dbaron: don't know the code well enough to come to a conclusion yet<br> <kbabbitt> noamr: seems like it animates to a discrete center<br> <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> <kbabbitt> ... I can come back with test cases<br> <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> <kbabbitt> ... need a separate issue on being able to express omitted value in offset-path<br> <kbabbitt> ... I'd like it if we could interpolate both cases but who knows if that's even possible<br> <kbabbitt> ... anything more for this issue?<br> <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