- From: Adam Argyle via GitHub <sysbot+gh@w3.org>
- Date: Mon, 30 Oct 2023 16:50:30 +0000
- To: public-css-archive@w3.org
I agree a sugar sweet way to specify an animation to play for DOM mutations would be useful. I've been thoroughly enjoying view transitions for this, and am very familiar with the naming dances that need to happen for it all to work. I'm going to try and share where my mind is dwelling on when comparing exit-style and view transitions, and where each can shine. For dom mutations and providing visual feedback to users, here's some of the transitions that are common: 1. transition out / exit stage: `remove()` 2. transition in / enter stage: `append()` 3. transition to a new location / move on the stage: combo of `remove` and `append` 4. transition to a new visual style: `.style = '…'` or `classList.toggle()` 5. reduced motion View Transitions has ways to handle all these scenarios, and i think with exit-style i'm most curious about configuration for when it shouldn't run. Like, if an element is moving position in a list, due to sort/filter/removal/etc. Would `exit-style` be a bit too blunt of an instrument for this case, as the elements would animate out (because they were removed) and then animate in again? If so, would I need to add a class to a "moving" element and ensure in my CSS that exit-style isn't applying to those? Now JS is articulating edge case handling, which is something we're trying to avoid here? To me, seems like exit-style is sugar for "certain" node removal scenarios and not all of them. And to prevent it from running I'd need to intervene with JS classes to inform selectors? It's almost like I'd like a way to tell exit-style which DOM mutations to observe and intercept for the exit animation. Meanwhile, view transitions have this logic already figured out. Authors can use CSS, no JS required beyond the call `.startViewTransition()`, to [distinguish and customize exit stage, enter stage, and move within stage](https://codepen.io/argyleink/pen/VwBKjwj). The tradeoff is naming, but afaik, angular and nearly every front-end framework now has unique ID tracking of loop rendered lists, which can make naming trivial. maybe there's a handoff point between exit-style and view transitions? exit-style for when you know the elements are only going to be removed and you want to animate it; view transitions when they might morph or change position in the dom? there's also `allow-discrete` which has some super powers in that it can delay the transition of elements in `overlay` or not, in addition to delaying `display:none` until just the right moment. lots of moving parts here! tldr; my biggest question is how do i tell exit-style when not to run? i can foresee moments where it'd run at times i'd like it not to, like sorting a list. -- GitHub Notification of comment by argyleink Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9500#issuecomment-1785649984 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 30 October 2023 16:50:31 UTC