[css-transforms] Smarter interpolation of truncated transform lists

[smfr]

https://www.w3.org/mid/CALXxKfCKZd+P0mH2oFyDkBgps56WqwQnLSMpKk1nrqiFXScqVA@mail.gmail.com
https://www.w3.org/mid/CAAWBYDBPafEbiXNy=Mw4a9w1jmvK6dUJzq28PPjN7APgtjqAEw@mail.gmail.com

Need to decide what goes into Level 1, and what to call the new identify functions. Related to #898

[alancutter]

This seems to be the key suggestion from the linked thread.

I wonder if we could take this a bit further - rather than just
removing identical prefixes (where both the functions and arguments
match), we could find the prefix that just has functions matching,
with potentially different arguments. Then we can interpolate that
common prefix normally, and run the rest of the two states back
through the list again as you describe, either matching the remainder
up with identity transforms or mashing the remainder up into a matrix.

My interpretation of this is that translateX(100px) scaleX(2) rotateX(90deg) interpolating with translateY(100px) scaleY(2) rotateY(90deg) would use pairwise function interpolation for translate and scale and use post multiplied matrix interpolation for rotate.

[smfr]

Propose moving to level 2.

[css-meeting-bot]

The CSS Working Group just discussed Smarter interpolation of truncated lists, and agreed to the following resolutions:

RESOLVED: Accept the issue as written.

The full IRC log of that discussion

<dino> Topic: Smarter interpolation of truncated lists
<dino> Github Topic: https://github.com/w3c/csswg-drafts/issues/927
<dino> smfr: we talked about this in seattle a bit. we suggested adding a special name that can match anything. e.g. identity or none.
<dino> smfr: should we add this to level 1?
<dino> smfr: there are some side-effects of not doing it - e.g. rotations greater than 360
<dino> smfr: i don't like that it is a behaviour change, so suggest deferring
<dino> TabAtkins: I'm ok with deferring any behaviour change
<dino> Rossen: there was a lot of discussion on this. Have you played with it?
<dino> smfr: we haven't implemented.
<dino> Rossen: what is the fear of compatibility risk?
<dino> smfr: they might get different animations
<dino> dbaron: since people have to manually write this, there is no compat risk
<dbaron> (assuming they do, at least)
<dino> smfr: this issue is also asking for magical matching (inserting identity transforms)
<dino> smfr: it's saying that it uses the common prefix for as much as possible, then smoosh together the rest into a matrix
<dino> dbaron: there is more compat risk there
<dino> dbaron: not sure how much interop there is here, since we've changed it a lot
<dino> TabAtkins: better behaviour would be nice, but yes there is a compat risk
<dino> smfr: could we change this behaviour in level 2?
<dino> Rossen: more risky
<dino> dbaron: if we want to change, do it in level 1
<dino> shane: there is a risk. i don't think it is a big issue though. i have no data to support it. we're talking about visual behaviour of an animation
<dino> shane: and this is a fallback behaviour that is now hopefully more closely matching the author intent
<dino> shane: i think this is only stopping messed up animations from looking messed up
<dino> birtles: it's hard to think of a case where it looks worse
<dino> smfr: so change the behaviour for Level 1? As the github issue suggests?
<dino> TabAtkins: that is the most reasonable way to intuit author preference here
<dino> smfr: right
<dino> <no one disagrees>
<dino> <wait.....>
<dino> dbaron: we'd be hesitant to be first implementation, but if everyone else agrees, then we're ok
<dino> Rossen: if we already resolved this, do we need to change anything?
<dino> smfr: i can't find it.
<dino> TabAtkins: i don't think we did
<dino> smfr: maybe we resolved this would be a L2 thing
<dino> Rossen: we can resolve it now
<dino> Rossen: objections?
<dino> <none>
<dino> RESOLVED: Accept the issue as written.

[smfr]

That resolution wording is obtuse, but I think means that we resolved to make the behavior change in transforms-1.

[birtles]

We started implementing this in Firefox but I'm a little unclear about the intention of this change. In the IRC log I see the comment:

smfr: it's saying that it uses the common prefix for as much as possible, then smoosh together the rest into a matrix

but in the spec change we seem to only handle mismatched lists where the functions of the shorter one match primitives of the longer.

i.e. it seemed like we were initially looking at allowing rotate(0deg) translate(10px) → rotate(720deg) scale(2) to interpolate the rotate() component directly and then use matrix interpolation for the remainder but the spec change would make the whole thing use matrix interpolation.

It may well be that the spec change deliberately doesn't allow the "common prefix" behavior due to compatibility concerns but I'd like to confirm we've understood the intention here since it's not clear to me from the IRC log what the outcome was.

[dirkschulze]

@birtles From the proposal and the discussion, the spec change does not fully support the requested "smoosh". According to the discussion above this could either be by:

• multiplying all not matching functions to a matrix and interpolate the others.
• adding neutral transform functions where needed.

Both do not sound ideal to me. The latter mostly because we need to define an algorithm where and when to add neutral transformations. At the first glance this might sound intuitive but really isn't.

I wasn't in the discussion but what @smfr added seems to be logical and matching the behavior of other CSS properties:

• Fill up the shorter list with matching, neutral transform functions.
• (Special requirement: only if the transforms are otherwise compatible.)

[birtles]

Yeah, it seems to be reasonable. I just wanted to check if the spec change was intentionally different from what the discussion seemed to conclude.