[motion-1] Serialization of offset-rotate

[BorisChiou]

Per the spec definition [1] and its wpt [2], the serialization of the specified values seems like:
(template: input => serialization of the specified value)

1. auto => auto
2. auto 0deg => auto 0deg
3. 0rad reverse => reverse 0rad
4. 0deg => 0deg

However, based on the shortest serialization principle, it seems the expected results are:

1. auto => auto
2. auto 0deg => auto
3. 0rad reverse => reverse
4. 0deg => 0deg

Just wonder is it possible to make the serialization simpler? Or is there any specific reason to keep the 0deg angle in the serialization?

This rule also applies to the computed value, I think.
(template: input => specified value => computed value)

1. auto => auto => auto
2. auto 0deg => auto => auto
3. reverse 0deg => reverse => auto 180deg

Besides, for computed value, it seems we always convert reverse xdeg into auto (180+x)deg, so it could be easier to do interpolation because no need to do an additional conversion, I guess.

[1] https://drafts.fxtf.org/motion-1/#offset-rotate-property
[2] https://github.com/web-platform-tests/wpt/blob/master/css/motion/parsing/offset-rotate-parsing-valid.html

cc @ericwilligers @emilio

[emilio]

So is reverse expected to go away at computed value time? Are reverse and auto values expected to be interpolable?

[emilio]

Oh it does look like it looking at the spec. That's fine, but I wonder why having reverse in the first place then, you can just do calc(180deg + angle). But sure.

[ewilligers]

The reverse is motivated by SMIL animateMotion rotate.
Otherwise, I don't think it would have been included.

If we have animation from auto 20deg to reverse -60deg,
should this flip at 50% progress or should animation be smooth?
If smooth, should the computed value at 60% progress be auto 80deg
or reverse -100deg? Smooth animation is most useful, but note that we
don't usually (ever?) have smooth animation when a keyword in the
computed value changes between keyframes.

The spec answers these questions by normalizing all
computed values to auto? <angle>:
"Computed value: computed <angle> value, optionally preceded by auto".

We have smooth animation, with auto 80deg at 60% progress.

[tabatkins]

Closing as invalid, because the spec doesn't specify serialization at all, and so the general CSSOM rules apply - shortest serialization, in grammar order.

As always, the "Computed Value" line says absolutely nothing about how to serialize the value; it describes the internal representation of the value, which is then used by serialization to produce a string that'll reproduce the same internal representation when re-parsed.

However, the WPT tests are thus wrong and need to be updated.