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

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 in either specifications or browser engines (and making sure it's reliable across all element types, all features that it needs to interact with, etc.) would be a *very* large amount of work.  (Without thinking about it very hard I'd guess that we'd be talking about engineer years of work for each browser engine, and I'd be hard-pressed to answer whether we're talking about a single-digit or a double-digit number of engineer-years.)

-----

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(odd) { 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[4].remove();
container.children[5].remove();
container.children[6].remove();
```

During their exit animations, is the background of the items `white` or `silver`?  Why?

Our normal practices for defining such behavior would be that the background of all three items would be `silver`, because at the time of their removal each item would be the 5th item in the container and thus the `:nth-child(odd)` selector would apply.  However, reaching this result requires flushing style at the start of *each* removal operation, which is very bad for performance -- it causes the pattern of frequent interleaving of reads and writes that we push authors to avoid.

Could we avoid this without adding additional APIs (which would then not satisfy the original requirement that the developer can use the normal removal APIs)?

Well, then, suppose we didn't flush style at all during the removals.  That would expose when the previous style flush was -- something that is entirely allowed to vary between implementations.  For example, if there was an earlier element inserted into the list prior to the removals, and implementations differed (which they can) on whether a style update happened since that insertion, then specifying that we not flush style would cause the background color to vary between implementations.

Could we avoid that without adding other APIs?  I don't think we can without doing something even more unreasonable (like flushing style before executing any script that comes after anything that might have been run asynchronously).

-- 
GitHub Notification of comment by dbaron
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9500#issuecomment-1786278931 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 01:11:20 UTC