[motion] offset-rotation should only do path-relative rotation

[fantasai]

Currently offset-rotation can specify an arbitrary rotation as well as a path-relative rotation. Afaict, this duplicates functionality in the rotate property, and therefore isn't really necessary.

The current syntax is

offset-rotation: [ auto | reverse] || <angle>

I propose

offset-rotation: none | forwards | backwards | <angle>

Where forwards computes to 0deg, backwards computes to 180deg, and any value other than none tracks the path tangent. (The choice of forwards and backwards keywords is to match the pair in animation-fill-mode.)

Alternatively, the value could also be dropped in favor of further tweaking with rotate.

[jihyerish]

I didn't know there is rotate property before, thanks for letting me know ;)
The < angle > value part of offset-rotation is obviously the same with that of rotate.

I'm in favor of dropping < angle > from the offset-rotation, so the syntax will be:

offset-rotation: none | forwards | backwards

[shans]

offset-rotation can't be used in place of rotate, and (to a degree) vice versa. Depending on the order of offset and translate/rotate/scale - if rotate happens after offset then these two are different:

offset: path("...") auto 45deg;
translate: 100px;

and

offset: path( ... ) auto;
translate: 100px;
rotate: 45deg

Alternatively, if rotate happens before offset then these two are:

offset: path("...") 45deg;

and

offset: path("...");
rotate: 45deg;

[shans]

I also want to strongly make the point that you keep talking about adjusting a specification that we have already shipped. We'd love to accommodate reasonable changes where we can (e.g. we've done this for the motion-* to offset-* rename, and are currently trying to determine if offset-rotation can be renamed to offset-rotate), but the larger the change and the later it's suggested the less likely we're going to be able to comply.

In practice the risk is that we have to support multiple variants of the feature (or just not support the new syntax at all, if it is dissimilar enough that we can't support both). This will potentially cause web compat problems.

[css-meeting-bot]

The CSS Working Group just discussed https://github.com/w3c/fxtf-drafts/issues/69, and agreed to the following resolutions:

• RESOLVED: Close issue #69 no change.

The full IRC log of that discussion

<shane> Topic: https://github.com/w3c/fxtf-drafts/issues/69
<shane> Github Topic: https://github.com/w3c/fxtf-drafts/issues/69
<TabAtkins> shane: First, issue was opened because you thought offset-rotation duplicated 'rotate'. I don't think that's true, and we should reject it.
<TabAtkins> shane: Second, this is a minor issue happening well after we shipped; we'd prefer to not make non-essential adjustments.
<fantasai> s/minor issue//
<TabAtkins> shane: Final output transform comes from several sources.
<TabAtkins> shane: offset, translate, rotate, scale, transform
<TabAtkins> shane: The order these happen in is quite integral to the result. Re-ordering is not generally possible.
<ericwilligers> https://drafts.csswg.org/css-transforms-2/#ctm
<TabAtkins> shane: So a rotation that happens in offset is different from one in TSR, which is different from one in transform.
<TabAtkins> shane: In particular, a rotate in "offset-*" rotates the frame of reference that the TSR properties work in.
<TabAtkins> fantasai: Do we *want* to do that?
<TabAtkins> shane: Yeah, definitely cases where you want to; you might be doing something independent in TRS.
<TabAtkins> fantasai: [describes some example she wants help with]
<TabAtkins> [something about additive properties not being possible yet]
<TabAtkins> [i believe the point is that the example in question is gonna need more control, probably in scripting, than we can reasonably provide in simple CSS anyway]
<fantasai> The use case is that you have the little motion path plan along its path, and then you want it to have an :active { /* shift it down/right by 2px to react to cick */ }
<fantasai> This should not require scripting
<TabAtkins> RESOLVED: Close issue #69 no change.