- From: Shrinivass Arunachalam Balasubramanian <notifications@github.com>
- Date: Sat, 14 Jun 2025 15:34:24 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1111/2973297496@github.com>
Shrinivassab left a comment (w3ctag/design-reviews#1111) Hi Stefan, TAG team, Thanks for sharing this, the explainer clearly highlights a performance bottleneck we have all encountered. I am particularly excited by the idea of triggering animations outside the window event loop, and I can see strong value for UI frameworks and design systems. Some thoughts and questions as a frontend engineer working primarily with Angular (and Signals-first state models): - Many component frameworks now encapsulate interaction logic (e.g., Angular, Lit, React). How might `animation-trigger` interact with Shadow DOM or scoped styles where the trigger/target span encapsulated DOM trees? - Would this allow fine-grained triggers tied to accessibility settings, like `prefers-reduced-motion` or assistive input methods? - Could there be extensibility for custom gestures (e.g., long press, pointer drag) in future iterations of this model? - Do you envision this working alongside frameworks that already use Signals/Reactive Graphs to model UI state (e.g., Angular 17+ with `@signal()` or React Compiler)? I’m exploring declarative reactivity architectures and wonder if `animation-trigger` could complement or inspire similar mechanisms in the framework layer. This proposal feels like a meaningful step toward bridging native-level smoothness in web UI. Happy to share examples or usage feedback as this evolves. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/1111#issuecomment-2973297496 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/1111/2973297496@github.com>
Received on Saturday, 14 June 2025 22:34:28 UTC