[css-logical] Logical properties should be animatable like the physical ones

[Loirooriol]

I don't see why this shouldn't be possible:

#element {
  animation: size 1s infinite alternate;
}
@keyframes size {
  from { inline-size: 100px }
  to { inline-size: 200px }
}

I expect it to animate just like if I used width. But the spec says

Animation type: discrete

On Chrome it's effectively discrete, on Firefox it doesn't animate at all. https://jsfiddle.net/45e6okrm/

[birtles]

From memory, we began implementing this in Firefox but never finished it. It's complicated by the fact that you can also animate the writing-mode etc. so that part-way through the animation the mapping for the properties changes, e.g.

#element {
  margin: 50px 100px;
  animation: yer 5s;
}
@keyframes yer {
  to { margin-inline-start: 200px; writing-mode: vertical-lr; }
}

As a result you can't just do the mapping to physical properties when you set up the animation. Instead you need to re-evaluate the mapping whenever the animated value of the writing-mode, direction etc. change.

[upsuper]

It's complicated by the fact that you can also animate the writing-mode etc.

If that's where the difficulty is from, maybe we should put writing-mode and direction into the category of properties that is not animatable. I don't see how animating them can be useful, and I guess it makes sense to get rid of the animatability of them if that gets in the way of other (useful) stuff.

[birtles]

(I should clarify that responding to changes in the animated value is more difficult than responding to other changes in the computed value.

In order to avoid triggering transitions due to animations, UAs need to distinguish between non-animated style updates and animated style updates. In Gecko we do this using a separate style resolution step for animations and I suspect in order to do transitions properly with regards to inheritance, other UAs will need to do something similar, if they don't already. As a result, while non-animation related changes will get picked up naturally during the animation styling, changes due to animation itself need special handling.

We already have a similar situation with font-size and custom properties but those only affect the property values where as this affects the property name mappings.)

[fantasai]

@upsuper Currently writing-mode, text-orientation, and direction are all listed as not animatable. (By contrast, unicode-bidi is listed as discretely animatable.)

[fantasai]

@Loirooriol Bikeshed is auto-filling the Animatable line in the propdef tables. :( It should really stop doing that. If the spec left out the Animatable line, it should either leave it out of the output or post an error.

[fantasai]

Fixed the Animatable lines to match their corresponding physical properties (as was always intended) in bfba9a7

@birtles Does there need to be any further clarifications anywhere else?

[birtles]

Yes, we should update Writing Modes spec to say "Animation type: none" since "Animatable: no" is often taken to mean "Animation type: discrete" (after we resolved that properties should be animatable by default and only a very small subset of properties should be marked as explicitly not animatable).

[Loirooriol]

Just as a reminder, display should also be updated: #72 (comment).

[css-meeting-bot]

The Working Group just discussed animating writing-mode/direction, and agreed to the following:

• RESOLVED: Fix unicode-bidi to be non-animatable, and make sure all propdefs are using the proper terminology.

The full IRC log of that discussion

<TabAtkins> Topic: animating writing-mode/direction
<birtles> Github: https://github.com//issues/2751
<TabAtkins> birtles: Like françois says, animation is tricky because they share the same computed properties
<TabAtkins> birtles: and animations works on computed values, so you need to do mapping to computed proeprties befor eyou animate
<TabAtkins> birtles: This is different to font-size
<fantasai> Actually, writing-mode, direction, and text-orientation aren't currently animatable anyway
<TabAtkins> birtles: There the dependency is between property *values*, but here it's a dependency between properties themselves
<fantasai> https://www.w3.org/TR/css-writing-modes-3/#direction
<TabAtkins> birtles: In gecko, we distinguish between properties from animation, and changes from OM.
<fantasai> https://www.w3.org/TR/css-writing-modes-3/#propdef-writing-mode
<TabAtkins> birtles: Re-resolving that mapping in response to aniation change is harder than in response to OM change
<TabAtkins> birtles: So it does add significant complexity
<TabAtkins> birtles: I think if we say they're not we still need to update the mapping from OM, and that's some complexity, but much less.
<TabAtkins> florian: Any use-case for animating?
<fantasai> [tab tries to imagine a use case, other ppl say it's not very credible use case]
<fantasai> heycam: Why are direction and unicode-bidi excluded from all?
<fantasai> TabAtkins: They shouldn't have been in CSS in the first place, they're really content attributes
<TabAtkins> fantasai: They're already described as "animatable: no"
<TabAtkins> florian: It's unclear whether that's the old meaning of "no" (meaning "discrete"), or the new sense (meaning not animatable)
<TabAtkins> fantasai: Currently unicode-bidi says "discrete" and the rest say "no", which doesn' tmake a lot of sense
<TabAtkins> astearns: So the proposed resolution is to take direciton/writing-mode/unicode-bidi and make them not animatable
<TabAtkins> shane: This'll be confusing for authors if they do put them in keyframes
<TabAtkins> fantasai: Authors already shoudln't be using direction or unicode-bidi in stylesheets
<TabAtkins> shane: That's a good argument in general, then!
<TabAtkins> RESOLVED: Fix unicode-bidi to be non-animatable, and make sure all propdefs are using the proper terminology.
<TabAtkins> frremy: With this resolution, I"m much happier about the previous topic.