[css-values-5] Should `interpolate-size` be a new value to animation/transition-behavior?

[nt1m]

We have transition-behavior: allow-discrete, so interpolate-size felt a bit inconsistent to me.

Should it be transition-behavior: allow-keyword-sizes or such?

cc @dbaron @tabatkins @fantasai for thoughts

[nt1m]

(I'm aware we don't have animation-behavior but perhaps it's a good time to add one, I believe @LeaVerou suggested it on a different issue)

[nt1m]

This is the current spec for interpolate-size: https://drafts.csswg.org/css-values-5/#interpolate-size

[dbaron]

The reason I didn't want to do it this way is described in #10294 (comment) and in #10294 (comment)

[nt1m]

Hmm, ok. How about size-interpolation to match color-interpolation? Just finding ways to make it consistent with the rest of CSS

[LeaVerou]

There is the open issue of how we set color interpolation space, perhaps we could combine these? E.g. interpolation-settings or something?

[dbaron]

@nt1m size-interpolation was one of the two proposals I used to start the discussion of bikeshedding the name -- so I would have been fine with it (particularly if it were the original decision rather than a later revisit), but the discussion at the face-to-face (minutes at #10294 (comment)) moved away from that suggestion.

@LeaVerou I don't want to combine it with something that people actually want to change, because this is designed to be a compatibility opt-in for something that we'd prefer to make the default but can't because of compatibility. It's something you should be able to set once on the root to opt in to the "correct" behavior and then never touch again. If we combine it with something else then people need to remember to re-state that opt-in at each use. See the minutes in #10294 (comment) (and some of the prior comments) for some discussion of this.

[LeaVerou]

@nt1m size-interpolation was one of the two proposals I used to start the discussion of bikeshedding the name -- so I would have been fine with it (particularly if it were the original decision rather than a later revisit), but the discussion at the face-to-face (minutes at #10294 (comment)) moved away from that suggestion.

@LeaVerou I don't want to combine it with something that people actually want to change, because this is designed to be a compatibility opt-in for something that we'd prefer to make the default but can't because of compatibility. It's something you should be able to set once on the root to opt in to the "correct" behavior and then never touch again. If we combine it with something else then people need to remember to re-state that opt-in at each use. See the minutes in #10294 (comment) (and some of the prior comments) for some discussion of this.

To re-iterate the feedback we gave in this feature’s TAG review, given that the result of the change is a slight glitch that doesn’t break actual readability, I think we should reconsider simply making the change rather than introducing these awkward opt-ins, or at least digging more into the data to get a fuller picture of the compat implications. We should not be introducing warts into the language simply to avoid examining the compat implications fully or just to be conservative, but when the impact of the wart on authors is genuinely smaller than the impact of the compat implications.

Or perhaps we can introduce certain restrictions that serve use cases while minimizing breakage. E.g. I wonder if it would be more web-compatible to only transition between these values when a width/height transition is explicitly requested, rather than when implicitly included via all (either explicit or omitted).

[dbaron]

I just responded about the all option in #626 (comment) ; I don't think that would be sufficient.

I think as far as browser engine developers go, I think I lean towards being willing to try to make changes that might cause small amounts of broken content. However, I think this is way past where I'm willing to go in terms of breaking content, because given the number of problems I saw on top site homepages I suspect there's going to be a large number of sites broken in various ways through the long tail of web content. I think the CSS WG has had extended discussions of compatibility problems whose effects were at least a hundred times smaller than this. I also think parts of a page moving around that the author didn't intend to animate can substantively affect usability and accessibility, and is more significant than "doesn't break actual readability".

[nt1m]

@dbaron Just one suggestion: can interpolate-size be named interpolation-behavior (analogous to transition-behavior)?

Something like interpolation-behavior: allow-size-keywords

The reason I suggest this, is because I could see more switches being added (choosing the color space for instance, or cross fading images for instance) and it would be nice to have it all in one property.

interpolation-behavior: allow-size-keywords color-space(oklab) or interpolation-behavior: allow-image-crossfade etc.

[dbaron]

@dbaron Just one suggestion: can interpolate-size be named interpolation-behavior (analogous to transition-behavior)?

Something like interpolation-behavior: allow-size-keywords

See my reply to Lea in #10576 (comment)