- From: Tab Atkins Jr. via GitHub <noreply@w3.org>
- Date: Tue, 26 Aug 2025 21:46:17 +0000
- To: public-css-archive@w3.org
I'd think this is potentially the exact use-case that `update: slow` is designed to handle. I suppose it's on the boundary, so we could supply some more guidance about matching it in this case. Note that MQs have an important and unstated design consideration, that using them needs to be as simple as possible (but no simpler), especially for these sorts of accessibility-adjacent MQs. That means, in many cases, it's worthwhile to over-simplify into big, chunky categories, so long as those categories match useful things authors can respond to. Our current intention with `update` is to just expose 3 categories: "this can display a smooth animation", "this can change, but not smoothly", and "this won't change after initial render". Responding to each of these is easy for authors - you probably want to react to `(update: slow)` by turning off animations and transitions, and to `(update: none)` by turning off UI interactivity entirely (auto-expanding all `details`, etc). Adding more categories to `update`, or making it a continuous metric like FPS, needs decent justification for the added detail, because when people have too many details to potentially respond to, especially ones they can't trivially reason about, they're more likely to give up and not deal with it at all. `(width)` is fine to be continuous, because it maps directly to meaningful sizes in your stylesheet, and you can just fiddle with your window to see how well it works. Trying to decide what FPS breakpoint to turn off a particular animation, on the other hand, is extremely subjective, with no right answer. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12654#issuecomment-3225829333 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 26 August 2025 21:46:18 UTC