- From: szager-chromium via GitHub <noreply@w3.org>
- Date: Mon, 28 Jul 2025 21:36:35 +0000
- To: public-css-archive@w3.org
Sorry I'm a bit late to the party, though I feel there are already sufficient cooks in the kitchen. Just want to make one general observation... It's natural to think of animation triggers as inherently a matched pair -- one to start the animation, another to stop -- but we have to be careful when applying that model to event-based triggers. Matching `mousedown` and `mouseup` events is intuitive, but we should avoid the temptation to think this is equivalent to `:active` via other means. In order to support the intended optimizations for event-based triggers, it's important that events are treated as instantaneous and stateless. The compositor thread can reasonably assess whether an incoming event meets trigger criteria; but it cannot easily evaluate or track DOM state (including CSS pseudo-states). I believe this is more or less equally true for all major implementations. I also think using matching `mousedown` and `mouseup` events as start/end triggers is appealing in the abstract but maybe not super useful in practice; I struggle to think of an application. Maybe a tickle-me-elmo app? It's easier for me to imagine uses cases where a series of clicks will play/pause or play/reset-and-play or play/reverse an animation. Those were the behaviors I had in mind when writing the PR for event-based triggers, I hope they will be straightforwardly do-able in whatever design we land on. -- GitHub Notification of comment by szager-chromium Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12336#issuecomment-3129952281 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 28 July 2025 21:36:36 UTC