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

I find it hard to understand why a basic view-related requirement would need to be implemented using JavaScript. I believe this is the responsibility of CSS itself. For example, in the implementation of a collapsible drawer menu, we always want the menu to appear smoothly from the side. We could naturally use `transition` to control this process. However, if we don't set `display: none`, we will still retain this element in the document flow, and even if the element is not in the view, then `Tab` can still jump to the menu. This is why `@starting-style` exists, and its counterpart is `@ending-style`. 

Another practical example is when editing tags. We want each tag to shrink and disappear naturally when deleted. Without `startViewTransition`, we need to add `removing` to classList for each element and `setTimout`. Ignoring the code's aesthetics, this can also lead to bugs because element removal is delayed. Even with `startViewTransition`, we still have problems. Suppose we delete multiple tags simultaneously; we know they will all apply the same animation, but now we have to specify different `view-transition-names`. I believe `@ending-style` can solve these problems.

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


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

Received on Tuesday, 3 February 2026 03:06:59 UTC