Display and content-visibility animations

[josepharhar]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Display and content-visibility animations
• Specification or proposal URL (if available): [css-display] Why is display listed as not animatable instead of animation type: discrete? w3c/csswg-drafts#6429
• Explainer URL (if available): [css-display] Why is display listed as not animatable instead of animation type: discrete? w3c/csswg-drafts#6429 (comment)
• Caniuse.com URL (optional): none
• Bugzilla URL (optional): none
• Mozillians who can provide input (optional): none

Other information

• TAG review: Display and content-visibility animations w3ctag/design-reviews#824
• WebKit standards position: Display and content-visibility animations WebKit/standards-positions#147

Support specifying display and content-visibility in animations. This support allows for developers to create exit animations after which the element automatically becomes display: none or content-visibility: hidden without needing to write any javascript to handle that switch after the animation is finished. This allows exit animations for elements to be added purely in CSS.

[zcorpan]

@dholbert @emilio thoughts?

[emilio]

@hiikezoe / @birtles / @BorisChiou might have thoughts as well.

Given the constraints it seems reasonable, but would be good to have proper spec text to evaluate, because there are a lot of questions about how to avoid circularity. (See fantasai's last comment in the issue)

[birtles]

I recall many years ago we tried making display animatable from the Web Animations API (since SVG SMIL animations can animate display and we wanted to rebase those on top of Web Animations) but ran into some scary crashes that we didn't have time to investigate.

In principle though, I think being able to animate display from Web Animations API is desirable. If the cyclic dependency issues can be resolved, doing it from CSS animations would also be good. I assume this is only about CSS animations (and Web Animations), not CSS transitions.

I'm not familiar with content-visibility so I don't have an opinion on that.

[hiikezoe]

Yeah, it sounds reasonable to me with the constraints.

@josepharhar Can you please mend the initial comment specifically this part?

This support allows for developers to create exit animations after which the element automatically becomes display: none or content-visibility: hidden without needing to write any javascript to handle that switch after the animation is finished.

It initially misled me that display property can be animated to display: none.

[josepharhar]

I assume this is only about CSS animations (and Web Animations), not CSS transitions.

No, I believe the goal is to support transitions as well

It initially misled me that display property can be animated to display: none.

These transitions/animations are animating to display:none, that is the main use case.

[hiikezoe]

It initially misled me that display property can be animated to display: none.

These transitions/animations are animating to display:none, that is the main use case.

Can you please clarify? In my understanding the current proposal does change display:none in keyframes to display:revert-layer to avoid the cyclic dependency issues, right? What I am currently understanding is that during the animation in question is running, we never get to display:none style, after the animation finished, the display style can be none with non-animating style, no?

[josepharhar]

after the animation finished, the display style can be none with non-animating style, no?

Yes, with my use case in mind, after the animation is finished the element will be display:none.

When closing a <dialog> element, it becomes display:none in order to get it off the screen. I want to be able to animate the dialog element while/after it is "removed", and have the style be display:none like it is supposed to after my animation has finished. This way the dialog can fade out when the user closes it.

[josepharhar]

I just commented on the CSSWG issue about implementing this: w3c/csswg-drafts#6429 (comment)