Re: [csswg-drafts] [css-transitions-2] Exit animations (`@exit-style`) (#9500)

@Loirooriol 
> I don't see how this would work. 

Yes, it's more challenging than `@starting-style` but it's such a common problem that I think it's worth spending some cycles on. Some ideas below.

> The thing about `@starting-style` is that when an element becomes rendered, it gets the styles from `@starting-style`, and then transitions towards the normal styles.
> 
> But with this, once the element stops being rendered, it immediately disappears, so no transition is possible. We would either need to delay the actual removal until the transition finishes, which seems to open a can of worms, or somehow detect that the element is going to be removed before it happens and start the transition then.

We cannot make removal async for a number of reasons. Beyond the obvious, one nonobvious reason is also that the exit style and the removal code may be written by different entities, and it's important for this to work well. E.g. I'm using a library which removes elements with no animation, so I write some styles to animate them.

We could however delay it (sync) for the instant it would take to apply exit styles. Then, the transition effect would be entirely visual and the element would be taken out of the DOM immediately. Probably with some safeguard against infinite animations that could keep its ghost around forever. An easy such safeguard could be to simply not support animations, or cut them off when all transitions finish regardless of where they are in their playback.

It could even be defined in terms of view transitions under the hood, just that the UA would generate it for you.

-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9500#issuecomment-1781298753 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 26 October 2023 14:57:10 UTC