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

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.

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.

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

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

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.

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

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:

Animation keyframes may specify display values which are not none. display: none is dropped from keyframes.
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;
}

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.

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

Agenda+ to resolve on the behavior Rob suggested here.

CSSDisplayAnimation: Don't cancel display:none animations

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

Bug 1824015 [wpt PR 39148] - CSSDisplayAnimation: Don't cancel displa…

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?

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.

Does this still need spec edits?

Navigation Menu

Repository navigation

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

47 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

flackr commented on Jul 7, 2021

LeaVerou commented on Jul 7, 2021

Loirooriol commented on Jul 12, 2021

flackr commented on Apr 14, 2022

tabatkins commented on Apr 14, 2022

flackr commented on Nov 17, 2022

chrishtr commented on Nov 18, 2022

css-meeting-bot commented on Nov 30, 2022

47 remaining items

chrishtr commented on Apr 11, 2023

flackr commented on Apr 13, 2023

flackr commented on Apr 25, 2023

css-meeting-bot commented on May 24, 2023

emilio commented on Jul 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions