- From: L. David Baron via GitHub <sysbot+gh@w3.org>
- Date: Tue, 31 Oct 2023 00:59:38 +0000
- To: public-css-archive@w3.org
I think the requirement stated in https://github.com/w3c/csswg-drafts/issues/9500#issuecomment-1783863101 -- to have the ability to do DOM node removal animations, starting from standard DOM node removal APIs that continue to have their usual effects on the DOM (synchronous removal), without unacceptable pre-removal performance costs -- just changes too many fundamental assumptions built into the Web. CSS has always worked on top of the DOM; we don't have the ability to render elements that aren't in the DOM, and changing that (and making sure it's reliable across all element types, etc.) would be a *very* large amount of work. There are also a bunch of very deep issues here that interact deeply with all of correctness, interoperability, and performance. Let me try to give a simple example. Suppose you have some sort of widget containing a list of items, each of which has `class="item"`. Let's say these items have exit animations (for when an item goes away), and that they have the style: ```css .item { background: white; color: black; } .item:nth-child(even) { background: silver; } ``` Now let's suppose a script comes along and removes the 5th, 6th, and 7th items in the container, in that order: ```js container.children(5).remove(); container.children(5).remove(); container.children(5).remove(); -- GitHub Notification of comment by dbaron Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9500#issuecomment-1786271255 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 31 October 2023 00:59:40 UTC