W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > May 2019

[fxtf-drafts] [motion-1] Serialization of offset-rotate (#340)

From: Boris via GitHub <sysbot+gh@w3.org>
Date: Wed, 22 May 2019 23:24:56 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issues.opened-447384325-1558567495-sysbot+gh@w3.org>
BorisChiou has just created a new issue for https://github.com/w3c/fxtf-drafts:

== [motion-1] Serialization of offset-rotate ==
Per the spec definition [1] and its wpt [2], the serialization of the specified values seem 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` => `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


Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/340 using your GitHub account
Received on Wednesday, 22 May 2019 23:24:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 22 May 2019 23:24:59 UTC