The CSS Working Group gave that a thumbs-up a couple weeks ago. The super-duper conceptual proposal being that we can animate or transition from, say, display: block
to display: none
.
It’s a bit of a brain-twister to reason about because setting display: none
on an element cancels animations. And adding it restarts animations. Per the spec:
Setting the
display
property tonone
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 thannone
will start all animations applied to the element by theanimation-name
property, as well as all animations applied to descendants withdisplay
other thannone
.
That circular behavior is what makes the concept seemingly dead on arrival. But if @keyframes
supported any display
value other than none
, then there’s no way for none
to cancel or restart things. That gives non-none
values priority, allowing none
to do its thing only after the animation or transition has completed.
Miriam’s toot (this is what we’re really calling these, right?) explains how this might work:
We’re not exactly interpolating between, say, block
and none
, but allowing block
to stay intact until the time things stop moving and it’s safe to apply none
. These are keywords, so there are no explicit values between the two. As such, this remains a discrete animation. We’re toggling between two values once that animation is complete.
This is the Robert Flack’s example pulled straight from the discussion:
@keyframes slideaway { from { display: block; } to { transform: translateY(40px); opacity: 0;}
} .hide { animation: slideaway 200ms; display: none;
}
This is a helpful example because it shows how the first frame sets the element to display: block
, which is given priority over the underlying display: none
as a non-none
value. That allows the animation to run and finish without none
cancelling or resetting it in the process since it only resolves after the animation.
This is the example Miriam referenced on Mastodon:
.hide { transition: opacity 200ms, display 200ms; display: none; opacity: 0;
}
We’re dealing with a transition this time. The underlying display
value is set to none
before anything happens, so it’s completely out of the document flow. Now, if we were to transition this on hover, maybe like this:
.hide:hover { display: block; opacity: 1;
}
…then the element should theoretically fade in at 200ms
. Again, we’re toggling between display
values, but block
is given priority so the transition isn’t cancelled up front and is actually applied after opacity
finishes its transition.
At least that’s how my mind is reading into it. I’m glad there are super smart people thinking these things through because I imagine there’s a ton to sort out. Like, what happens if multiple animations are assigned to an element — will none
reset or cancel any of those? I’m sure everything from infinite animations, reversed directions, and all sorts of other things will be addressed in time.
But what a super cool first step!
So, you’d like to animate the display property originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.