- From: Chris Harrelson via GitHub <sysbot+gh@w3.org>
- Date: Fri, 27 Oct 2023 22:36:50 +0000
- To: public-css-archive@w3.org
> I should probably stop replying late at night, but now that I've reread [#9500 (comment)](https://github.com/w3c/csswg-drafts/issues/9500#issuecomment-1781298753) more carefully I see Lea's point about immediate DOM removal being important -- and given that I agree that something built on top of view transitions is probably best. But I could imagine building it on top of view transitions in interesting ways.
I can also see the developer difficulty, but keeping track of a now-gone DOM element and where it used to be until the end of the animation is very difficult/maybe impossible. Even keeping it until the next render and a View Transition can start is hard and in general almost as hard. The alternative of stalling the rendering pipeline to get a screenshot of the pixels for a View Transition is possible, but that comes at a very high cost of forced layout, stalled pipeline, and memory impact.
OTOH the developer code to do it async would be something like:
```
startViewTranstion(() => { removeNode(); });
```
(setting it to `display:none` is already doable with `allow-discrete` has the same effect visually but of course not in terms of DOM state)
Which is certainly not as easy for the developer to deal with, but also seems feasible.
--
GitHub Notification of comment by chrishtr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9500#issuecomment-1783581634 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 27 October 2023 22:36:51 UTC