W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2019

Re: [csswg-drafts] [css-transforms-2] Serialization of individual transform when the animation is at 0% or 100% (#3290)

From: Boris Chiou via GitHub <sysbot+gh@w3.org>
Date: Tue, 08 Oct 2019 21:52:28 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-539719709-1570571547-sysbot+gh@w3.org>
This should be a general issue I think. IMO, when running an animation, `getCompustedStyle()` should return the current interpolated value, even at 0% and 100%. This issue may happen frequently on individual transform because `none` is converted into an equivalent interpolable value and we may promote 2d transform to 3d transform if needed, so the interpolable value could be different from the keyframe value.
More examples, on Gecko:
```
from { rotate: none; }
to { rotate: 4 5 6 45deg; }
```
While calling getComputedStyle() at 0%, the returning interpolated value is something like `(4 5 6 0deg) * 1.0 + (4 5 6 45deg) * 0.0`, so the result is `4 5 6 0deg`

```
from { rotate: 45deg; }
to { rotate: 1 -1 0 60deg; }
```
While calling getCompustedStyle() at 100%, the returning interpolated value is something like `(0 0 1 45deg) * 0.0 + (1 -1 0 60deg) * 1.0` and then do normalization on the axis part, so the result is `0.707 -0.707 60deg`.
While calling getCompustedStyle() at 0%, the returning interpolated value is something like `(0 0 1 45deg) * 1.0 + (1 -1 0 60deg) * 0.0` and then do normalization on the axis part, so the result is `0 0 1 45deg`, which is serizlized as `z 45deg`.

> Blink is short-circuiting the interpolation at 0%/100%, so we don't expand (say) 2 1 to 2 1 1, and thus output just two number (which is a valid serialization)

But basd on the serialization part, if it is a 3d trasnform, we should serialize it as a 3d, right?

-- 
GitHub Notification of comment by BorisChiou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3290#issuecomment-539719709 using your GitHub account
Received on Tuesday, 8 October 2019 21:52:29 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:54 UTC