- From: Christoph Päper via GitHub <noreply@w3.org>
- Date: Tue, 14 Oct 2025 13:10:23 +0000
- To: public-css-archive@w3.org
Since [MQs](https://drafts.csswg.org/mediaqueries/#update) are not only used with(in) CSS, but are also available in `media` attribute values or [as part of others](https://html.spec.whatwg.org/multipage/images.html#sizes-attributes) of some markup languages, particularly [HTML](https://html.spec.whatwg.org/multipage/embedded-content.html#the-source-element) and SVG, for clients selecting the optimal variant of embedded media resources, offering videos with a lower frame rate would be an obvious use case for an intermediate value: ~~~~ html <video> <source media="update: slow" src="slideshow.apng"/> <source media="update: smooth" src="tv-i30.mov"/> <source media="update: fast" src="hd-p60.m3u"/> <img src="static.jpeg/> </video> ~~~~ On `slow`ly updating surfaces (whether inherent or temporary), authors might want to disable most or all view transitions, animations (including images and videos) and hover effects, but perhaps keep dynamic `:visited` or `:target` styles for instance. They could also prefer overflowing segmentation over scrolling as well as expanding collapsible content. If (some) transitions remain, they could prefer [step-wise easing functions](https://drafts.csswg.org/css-easing/#step-easing-functions) over continuous ones or dissolving effects over sliding ones. On `smooth` screens, most of these limitations can be lifted. Authors might choose to restrict the design to a single moving part being visible at any time, i.e. no concurrent animations or effects. Also, playback of media elements could wait for user initiation or at least pause while the content is scrolling/panning instead of starting automatically and continue running whenever inside the viewable area. It may sometimes also be preferable to use prerendered, frame-based videos instead of live-drawn, possibly interactive animations reserved for `fast` displays (although that may more correlate with computing power available). The point is that any updates are clearly noticeable to viewers on `slow` devices, so authors should limit them to the bare minimum, whereas `smooth` screens would usually only exhibit perceptible flicker if there was too much or too fast movement, so authors would only scrap some extremes. That being said, I could see some vendors choosing `smooth` over `slow` for energy-saving modes. -- GitHub Notification of comment by Crissov Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12654#issuecomment-3401727093 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 14 October 2025 13:10:24 UTC