[css-display] Why is display listed as not animatable instead of animation type: discrete?

[LeaVerou]

https://www.w3.org/TR/css-display-3/#the-display-properties

I thought we were going for discrete for all properties that can't be intelligently interpolated, and that "not animatable" was reserved primarily for animation properties and the like?

Especially about display, there are plenty of use cases where authors want to finish an animation with display: none, and this prevents them from doing so.

[flackr]

display does affect CSS animations in the same way as animation properties. Specifically from https://www.w3.org/TR/css-animations-1/#animations

Setting the display property to none will terminate any running animation applied to the element and its descendants. If an element has a display of none, updating display to a value other than none will start all animations applied to the element by the animation-name property, as well as all animations applied to descendants with display other than none.

This means that if a CSS animation animated to display: none it would immediately cancel the animation, losing the display: none which would restart the animation.

[LeaVerou]

Ah, bummer. "Not animatable" makes total sense then.

[Loirooriol]

Just for reference, at some point display was animatable on Firefox, but that could freeze the browser. https://bugzil.la/1264396

[flackr]

I wonder if we could support only specific values of display, e.g. anything but none on css animations, and possibly anything on web animations since their lifetime is not controlled by the display property. Then you could create an animation which maintains display: block until it finishes or use a web animation.

[tabatkins]

Having only some values animateable would be a new concept, but yes, that would work and probably be useful.

[flackr]

Reopening this to consider allowing animations of display to prevent the element from immediately computing to display: none.

In particular, my straw-man proposal is the following:

1. Animation keyframes may specify display values which are not none. display: none is dropped from keyframes.
2. Display is interpolated like visibility, i.e. it will prefer the non-none value.

With these two points, we shouldn't have any circularity. An animation cannot itself produce display: none since it can't specify it (rule 1). Transitions to display: none would in theory work since the display: none wouldn't apply until after the transition finished (rule 2), however since display is a discrete animation it would still skip immediately to none per css-transitions-1 transitionable rule. Issue #4441 explores ideas for relaxing this if discrete properties are explicitly listed.

With this, developers could do things like:

.hide {
  transition: opacity 200ms, display 200ms;
  display: none;
  opacity: 0;
}

Or:

@keyframes slideaway {
  from { display: block; }
  to { transform: translateY(40px); opacity: 0;}
}

.hide {
  animation: slideaway 200ms;
  display: none;
}

[chrishtr]

With this, developers could do things like

Just to add on: this should also work for an "entry" animation from display:none to display:block with the same proposed change.

[css-meeting-bot]

The CSS Working Group just discussed [css-display] Why is display listed as not animatable instead of animation type: discrete?, and agreed to the following:

• RESOLVED: adopt this proposal, and work out the details

The full IRC log of that discussion

<fremy> flackr: Display is currently not animatable
<fremy> flackr: mostly because none would cancel the animation
<fremy> flackr: but there are valid use cases
<fremy> flackr: my proposal is to allow animation
<fremy> flackr: but flip "none" when the animation reaches 100% only
<fremy> flackr: we would need this restriction, because web animations would allow the animation to continue even if the element goes away
<fremy> flackr: so, the idea is that if we interpolate between two values
<fremy> flackr: the non-"none" value would win
<fremy> astearns: what is smfr's take on this?
<fremy> astearns: he isn't on the call
<fremy> astearns: anybody can take this over for him?
<fremy> heycam: at first glance, this seems reasonable
<fremy> heycam: I can't see any reason why this would cause issues
<PaulG> q+
<fremy> TabAtkins: the fundamental problem is going from "none" to something
<fremy> TabAtkins: but there are also values that change box types
<fremy> TabAtkins: and that makes it difficult to preserve an animation across box-generation changes
<fremy> TabAtkins: but we could define that
<fremy> emilio: writing mode an direction can affect animations as well
<fremy> fantasai: and text-orientation
<fremy> fantasai: but leaving those as non-animatable seems fine
<fremy> TabAtkins: that categorization makes sense to me
<astearns> ack PaulG
<emilio> q+
<fremy> paulg: this can be usedf to keep a distracting and harmful element visible using an animation that never lets "none" apply, troll the user with an animation
<ydaniv> q+
<fremy> fantasai: a user stylesheet can disable the animation
<fremy> fantasai: so this wouldn't make a difference, I think
<fremy> fantasai: there might be bugs in user agents right now, but this is what I expect
<fantasai> s/I expect/is specced/
<fremy> PaulG: but !important would not override the animation
<fremy> fantasai: no, animations are in the cascade
<fremy> fantasai: so !important static would override the animation
<fremy> PaulG: so you don't have to override the animation property?
<astearns> ack emilio
<fremy> fantasai: no, the property is enough
<fantasai> -> https://www.w3.org/TR/css-cascade-5/#cascade-sort
<fremy> emilio: one question about the behavior: what happens if you put display:none on a keyframe? is that allowed?
<fantasai> -> https://drafts.csswg.org/css-cascade-3/implementation-report
<fremy> emilio: at parse time that is not allowed
<fremy> emilio: but you can sneak this using a custom property
<fremy> flackr: yes, we want to make sure some properties should stay within acceptable values
<heycam> q+
<fantasai> (Safari currently doesn't handle animations cascade correctly, but Gecko and Blink do)
<fremy> emilio: and if doesn't ? what would happen?
<fremy> flackr: I guess not having a display value
<fremy> emilio: so, make display:none in the animation behave as display:revert (use the value outside of the animation)
<fremy> emilio: we can work out the details later though
<fremy> flackr: there is no circularity with web animations, so display:none doesn't stop the animation
<astearns> ack ydaniv
<fremy> emilio: right
<fremy> ydaniv: "discrete" animation flip half-way
<fremy> ydaniv: can we instead flip where the author wants it?
<fremy> flackr: this is the second part of my proposal
<fremy> flackr: the value would not change, until you reach the keyframe that sets the value
<fremy> ydaniv: and what about other values?
<fremy> ydaniv: isn't it more predictible if it always behave as a flip?
<fremy> flackr: I think this gives less flexibility to the developers
<fremy> flackr: they can still choose to have the keyframes have any duration
<fremy> flackr: if you flip immediately, this duration is no longer something the author controls
<fremy> astearns: are we not concerned by using a different timing for display than other values?
<fremy> ydaniv: I would suppose that other wanting to go from grid to flex don't want to wait
<fremy> flackr: all discrete proposals behave like that
<fremy> TabAtkins: and you can control where that 50% happens by having another keyframe
<astearns> ack heycam
<fremy> astearns: but for none, we need something special
<fremy> heycam: what about transition:all?
<fremy> flackr: no, because all only affects non-discrete properties
<fremy> flackr: we could enable transitions for more, but we would probably make a new keyword
<fremy> astearns: any other comment on this proposal?
<fremy> astearns: any concern about going further?
<fremy> astearns: proposed resolution is to adopt and start writing the spec text
<fremy> astearns: any objection?
<fremy> RESOLVED: adopt this proposal, and work out the details
<fantasai> Note: this should go into display-4

[Loirooriol]

It's worth noting that the outer display type can already be discretely animated (indirectly, and with side-effects), e.g. by setting display: inline-grid outside of animations, and then animating position/float to trigger a blockification into display: grid. See #6846 (comment)

[jakearchibald]

Comment moved to #8389

[yisibl]

Chrome 111.0.5545.0 is already supported and requires a Flag:

/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --enable-blink-features=CSSDisplayAnimation

Demo: https://codepen.io/yisi/pen/RwBzqGE

2023-02-10.15-12-21.mp4

[josepharhar]

I think I'd like to confirm with the other implementers what is the easiest set of restrictions to implement, whether it's easier to be more targetted about it or to be more broad about it.

So when I was experimenting with animating content it seemed like Firefox didn't stop animating the pseudo-element even when content was none. This got me wondering whether we could only remove animations if the base computed display style AND the computed display style is none. This might I think fix the circularity issues and allow the feature to work the simple way that a developer would expect.

I have implemented both display:none->display:revert and flackr's idea here of not canceling the animation when the animation sets the style to display:none. Unless there are edge cases I'm not thinking of, both were similar in difficulty to implement. I don't have a preference yet of which we should go with, but I defer to flackr's judgement.

To implement display:none->display:revert, I modified the style resolution code in parts where it knows that the style is being applied for an animation to change display:none to display:revert. It required additional changes in another spot to handle this case with variables:

@keyframes hello {
  0% { --display-value: none; }
  100% { --display-value: none; }
}
#target {
  display: var(--display-value, block);
}
#target.animation {
  animation-name: hello;
  animation-duration: 1s;
}

To implement not canceling the animation when an animation sets display:none, I used similar spots in the style resolution code but set a flag on the element when the animation sets display:none, so that the element knows that it shouldn't cancel the animation right after it recalcs its own style.

use cases

Not canceling the animation provides the ability to animate to display:none and back with keyframes during an animation and actually make the element disappear, but I don't know if that's a use case that we need to support. Here is an example of what that would look like:

@keyframes {
  0% { display: block; }
  20% { display: none; }
  80% { display: none; }
  100% { display: block; }
}

Display is interpolated like visibility, i.e. it will prefer the non-none value.

Due to this visibility-like behavior, none of the following use cases will be affected by the display:none->display:revert or don't cancel the animation behavior because there has to be a full interpolation step to and from display:none. All of these examples will be display:block for the entire duration of the animation regardless of which implementation option we choose.

@keyframes {
  0% { display: block; }
  100% { display: none; }
}

@keyframes {
  0% { display: none; }
  100% { display: block; }
}

#target {
  display: block;
  transition: display 1s;
}
#target.animated { display: none; }

#target {
  display: none;
  transition: display 1s;
}
#target.animated { display: block; }

[flackr]

Thanks @josepharhar for the implementation experience!

I believe that changing the cancellation rules for css animations to be only when the base computed style and the animated display style both produce none is much simpler to understand and explain, so I'd like to propose going with this since the implementation experience suggests that this works (and also that it has fewer special cases).

This is also consistent with the way that animations of content to none on pseudo-elements behave in Firefox today (animation keeps running), and conceptually similar to animating visibility.

[josepharhar]

To implement not canceling the animation when an animation sets display:none, I used similar spots in the style resolution code but set a flag on the element when the animation sets display:none, so that the element knows that it shouldn't cancel the animation right after it recalcs its own style.

the implementation experience suggests that this works (and also that it has fewer special cases).

Yeah it turns out that not canceling the animation is much easier to implement, I actually don't need to mess with the style resolution code at all that I mentioned earlier like I did in order to implement the display:revert behavior

[chrishtr]

Agenda+ to resolve on the behavior Rob suggested here.

[KevinDoughty]

There is no distinction between computed and animated values, is there? Aren't they one and the same? I asked for this distinction a decade ago in public-fx, because the pattern I call relative animation doesn't need current animated values for interruption. It only ever needs discrete values. Also, the underlying value is not necessarily discrete, which also confused me ten years ago.

Is or is not the comment I made almost eight hours before flackr the same solution?

This is what I wrote: #6429 (comment)

Instead of removing animations when set to none, remove animations when the computed value resolves to none.

This is what flackr wrote less than eight hours later: #6429 (comment)

This got me wondering whether we could only remove animations if the base computed display style AND the computed display style is none.

And then yesterday: #6429 (comment)

only when the base computed style and the animated display style both produce none

Can someone please explain the difference? If not, please make the distinction between discrete and animated computed values in specification. Is there a new definition in css-cascade-4, css-cascade-5, or css-cascade-6? They're hard to read since they are in some .bs format (no pun intended).

Another question, will something like this be possible? #6429 (comment)

animate display by setting a transition with a step-end easing on the display property. But also, create a class with an animation on the display property with keyframes from block to block.

It would make a lot of sense for front-end developers:

@keyframes displaying {
    0% { display: block; }
    100% { display: block; }
}
#target {
    transition: display 1s step-end, opacity 1s linear;
    animation: displaying 1s linear;
}
.in {
    display: block;
    opacity: 1;
}
.out {
    display: none;
    opacity: 0;
}

Would this work? Can we please make it work? If not, why?

[KevinDoughty]

I think my code suggestion fails on interruption, animating in, then reversing back out. Or, animation and transition rules would need to be different, which isn't good. Still would like discrete and animated computed values, hopefully someone else will too.

[flackr]

There is no distinction between computed and animated values, is there? Aren't they one and the same? I asked for this distinction a decade ago in public-fx, because the pattern I call relative animation doesn't need current animated values for interruption. It only ever needs discrete values. Also, the underlying value is not necessarily discrete, which also confused me ten years ago.

Is or is not the comment I made almost eight hours before flackr the same solution?

This is what I wrote: #6429 (comment)

Instead of removing animations when set to none, remove animations when the computed value resolves to none.

This is what flackr wrote less than eight hours later: #6429 (comment)

This got me wondering whether we could only remove animations if the base computed display style AND the computed display style is none.

And then yesterday: #6429 (comment)

only when the base computed style and the animated display style both produce none

Can someone please explain the difference? If not, please make the distinction between discrete and animated computed values in specification. Is there a new definition in css-cascade-4, css-cascade-5, or css-cascade-6? They're hard to read since they are in some .bs format (no pun intended).

The base word is the key difference here. This is referring to the style before the animations and transitions cascade. The computed value will resolve to none if we allow the animation to include display: none in its keyframes which then leads to the problematic circularity.

However, if the value before the animations part of the cascade is also none then when the computed value becomes none canceling the animation will not restart the animation.

I've taken a pass at writing the spec updates for this in #8713

[KevinDoughty]

At the risk of sealioning, I just want to say this will probably not work as is with my (experimental and unapproved by the W3C) desired changes for discrete state:
https://phabricator.services.mozilla.com/D156634#5139009

These are flackr's changesets and diffs for my or anyone else's future reference:
https://chromium-review.googlesource.com/c/chromium/src/+/4356155
https://chromium.googlesource.com/chromium/src/+/40601f60e9d413ca1fad4891041c0f43925a7f7e%5E%21/
https://chromium-review.googlesource.com/c/chromium/src/+/4363078
https://chromium.googlesource.com/chromium/src/+/1cc90dd5bb6ba48e9b359d3e93e8223e7eae98de%5E%21/

[flackr]

At the risk of sealioning, I just want to say this will probably not work as is with my (experimental and unapproved by the W3C) desired changes for discrete state: https://phabricator.services.mozilla.com/D156634#5139009

Can you be more specific? In particular,

• Can you confirm "this" is the part of the proposal for allowing animations to continue running as long as base non-animated display is not none?
• What specifically makes it not work with the discrete state changes? I didn't quite follow from reading the linked proposal why it doesn't work?

[KevinDoughty]

Can you be more specific?

I've been incapacitated, again, but will try to make a coherent proposal to sustyweb.

[css-meeting-bot]

The CSS Working Group just discussed [css-display] Why is display listed as not animatable instead of animation type: discrete?, and agreed to the following:

• RESOLVED: When an animations produces display none it continues to run but it still cancels animations within that subtree.

The full IRC log of that discussion

<bramus> flackr: Ill take this
<bramus> flackr: we resolved to make display animatable but tried to prevent two values of none being animated, but there were lot of edge cases like variables
<bramus> flackr: also problem with animate content on pseudos
<fantasai> TabAtkins, your proposed <position> syntax has multiple errors so, no. ^_^
<bramus> flackr: if you animate ocntent, it destroys the pseudo
<bramus> flackr: added something to css-animations-2 that we only cancel animations if the computed value of display and the value of display before the animoatins cascade is none
<bramus> flackr: if an animt produces display none so it continues to run instead of restarting
<emilio> q+
<bramus> flackr: beahves like develoeprs expect it to work
<bramus> flackr: also consistent with content animations in firebox
<bramus> emilio: not sure is content behavior in firefox is intentiional
<bramus> emilio: how does this interact with nested elems?
<bramus> emilio: presumably we want to cancel animations deep in display none subtrees
<bramus> flackr: good q
<bramus> flackr: I think there is no lifetime issue if we want to cancel anims in nested elements
<bramus> flackr: i would be fine with saying that behaviour should only look at the style without local animaotins and the ancestor style can include all animated styles
<bramus> emilio: not sure if i follow
<bramus> emilio: when the display value becomes ?? – I think blink also has a mechanism to clear stuff down the tree?
<bramus> emilio: presumably we cancel animations then?
<bramus> flackr: in blink the anims are associated with the element so we can still remove all of the layout structured associated with it
<bramus> flackr: q is if animations keep on living
<bramus> flackr: and if their time restarts or not
<bramus> flackr: we still need to keep computed style for to plevel display none elem to know it is display none
<bramus> flackr: so i thikn that nested elements should just be cancelled to reduce overhead
<bramus> emilio: i think we should cancel them, eys
<bramus> s/eys/yes/
<bramus> emilio: need to specify when that happens?
<bramus> flackr: spec needs a slight change to reflect that it doesnt apply to nested elements
<bramus> flackr: can do an update
<bramus> emilio: OK
<bramus> flackr: Proposed resolution; when an animations produces display none it continues to run but it still cancels animations within that subtree
<bramus> Rossen_: Objections? Qs?
<bramus> RESOLVED: When an animations produces display none it continues to run but it still cancels animations within that subtree.