[css-transforms-1] Presentation attribute as start or end value of a CSS transition

[dirkschulze]

Implementations differ when start or end value of a CSS transition is defined by a transform presentation attribute. I'll investigate and add examples.

[dirkschulze]

Test

I created a test case here: https://codepen.io/krit/pen/XqvqyG?editors=1100

The behavior is different across browsers:

Interpolation	transform="rotate(45) scale(2)" to transform: rotate(3turn) scale(1)
WebKit	transform attribute gets ignored; from-value turns to none.1
Blink	Interpolation per transform - as speced.
Gecko	transform attribute gets ignored; from-value turns to none.
Edge	Interpolation per transform - as speced.

1. After the transition back to from the value doesn't get reset to attribute value.

Interpolation	transform="rotate(45 50 50) scale(2)" to transform: rotate(3turn) scale(1)
WebKit	transform attribute gets ignored; from-value turns to none.1
Blink	No interpolation.
Gecko	transform attribute gets ignored; from-value turns to none.
Edge	Interpolation per transform. from-value ignores translation of rotate(45 50 50)

1. After the transition back to from the value doesn't get reset to attribute value.

Conclusion

• Blink and Edge do interpolation per transform function for all CSS supported transform functions as speced.
• No implementation does fall back to matrix decomposition if rotate() has translation/origin values.

[AmeliaBR]

My thoughts:

• Having an existing transformation suddenly disappear at the start/end of a transform is very bad behavior.

• Ideally, the values would be interpolated according to the usual algorithm, with px/deg units serialized in.

• If that is not possible for implementations, then the entire attribute should be condensed into a single matrix transformation, and that used for interpolation.

The 3-value rotate function is a little trickier. According to the current spec text, it is one of the primitive transform functions, and the simple rotate function should be upgraded to the 3-value form and then transitioned. But since the 3-value form is legacy-only, I think it would be acceptable to change the spec so that the 3-value form is treated as its own unique function that doesn't transition to any other rotate form (i.e., forcing the transition to use the cumulative matrices).

(PS, @dirkschulze I changed the Agenda+ label, assuming you weren't intentionally deferring discussion until the August F2F.)

[dirkschulze]

@AmeliaBR The current WebKit behavior (not returning to attribute value) for sure is a bug. Just thought I'd mention it here as well. I think that the behavior of Edge is a bug too or a compromise for simplicity reasons. Maybe @dstorey or @atanassov know.

The current spec text reflects your expectation for the most part I think. I missed to remove the 3-value rotate() function from the primitives transform function list but had the intention to do so. I agree that it should be seen as legacy. Nevertheless (as you seem to agree) it should not just be ignored or reduced to its rotation for interpolation IMO.

And yes, I hope we can agree on the behavior that we already have for interpolation between 2 CSS property values and find a solution for the 3-value rotate(). The spec text request matrix interpolation if the transform list contains a 3-value rotate().

IMO this is might be an extremely rare case anyway but should be clarified since implementations differ.

[AmeliaBR]

IMO this is might be an extremely rare case anyway

I usually recommend that authors use the transform attribute for core aspects of the design (for backwards compatibility), and then use CSS transforms as progressive enhancement, such as :hover effects or media query adjustments. It is quite reasonable that an author would try to add a transition between the base and the enhanced state. So that much I'd consider core functionality.

Transitioning from/to a 3-value form is less likely, but it still needs an unambiguous behavior.

[tabatkins]

Yeah, I think it's most reasonable to just treat the 3-value rotate() as a new primitive that's compatible with nothing (including itself), so you always get matrix interpolation if it's used.

[birtles]

For Gecko, the behavior in the second comment is just because we haven't made transform a presentation attribute yet. See Mozilla bug 878346 and bug 1435443.

/cc @emilio, @heycam

[css-meeting-bot]

The Working Group just discussed Presentation attribute as start or end value of a CSS transition, and agreed to the following:

• RESOLVED: use edge behavior
• RESOLVED: make this rotate with 3 values transition to a matrix and do matrix decomposition

The full IRC log of that discussion

<dael> Topic: Presentation attribute as start or end value of a CSS transition
<dael> github: https://github.com//issues/2684
<dael> krit: In SVG we have the transform attribute which is a presentation attr which mean sit contributes to css pipeline and we can set a transform and it would interfere in hierarchy with itself.
<dael> krit: If we have a transform with a list and define a transition on the same element, should it take transofrm into account or just ignore? I'm asking for ignore. 2 browsers do that and 2 take it into account.
<krit> https://codepen.io/krit/pen/XqvqyG?editors=1100
<dael> krit: codepen^
<dael> krit: You can see that there's a transform on the rect and a transition in css. For webkit you see it transforms and then transforms. blink and edge take the transform from the transform attr and then transition to the value.
<dael> krit: I'd like to ignore as that makes the most sense. So can a transform attr contribute as a start or end value?
<dael> krit: I'm asking for edge or blink behavior.
<dael> astearns: Conserns with standardizing on blink or edge?
<dael> smfr: Good to match other presentation attributes
<chris> LGTM
<dael> astearns: And there's a Mozilla comment saying it's because they haven't made transform a presentation element yet
<dael> RESOLVED: use edge behavior
<dael> krit: Syntax and some transform are different then on css. Example is rotate which is 1 value in css, 3 in SVG.
<dael> krit: If we have a transition from a transform presentation attribute with 3 value rotate to css, css would not understand. Edge here ignores the origin so the element jumps and then contiues. Blink composes from one matrix to another
<dael> krit: Webkit and FF ignore.
<dael> krit: Proposal would be to make this rotate with 3 values to a matrix and do matrix decomposition
<dael> astearns: This is an edge case b/c 3 value isn't used much?
<chris> rrsagent, here
<RRSAgent> See https://www.w3.org/2018/06/20-css-irc#T16-53-26
<dael> krit: Yes. Edge case because css does not have 3 value so it's not often used.
<dael> smfr: Unfortunate that you fall back to matrix for something that's a rotate...you'll never do rotate [missed] turning into rotate translate
<dael> krit: You could change rotate to a rotate translate, but that could be worse becuase it doesn't match any transform function. So we'd still fallback
<TabAtkins> (I support the rotate(3-arg) being incompatible with anything.)
<dael> krit: Proposal is if there's a rotate with 3 values and have a transition it gets composed to a matrix and we have matrix decomposition for a animation
<dael> smfr: No alternate proposal and I don't object. It's okay, it's just that if author is trying to rotate we will fallback
<dael> krit: Can we agree on matix decomposition?
<dael> astearns: Objections to make this rotate with 3 values to a matrix and do matrix decomposition
<chris> ok I guess
<dael> RESOLVED: make this rotate with 3 values transition to a matrix and do matrix decomposition