[mediaqueries] media feature for reduced frame rate (due to low energy/battery saver mode)

[knowler]

Often when devices enter “battery saver” or low power mode, they will reduce the frame rate of animations (might be tied to reduced refresh rate? idk). This can make an animation so choppy that they might not be worth having, especially when there is motion. I’d love to have a way of querying this.

The update media feature exists with the keywords none, slow, and fast, but slow is very slow, so fast will almost always be triggered. Feels not totally related to what I want. We almost need an in-between keyword or maybe an entirely different media feature. It might even be nice to query a range (i.e. if the device can do more than x frames per second, then show the animation).

[tabatkins]

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.

[Crissov]

I agree that there is no real benefit in exposing a numeric refresh rate.

However, it could be worthwhile to add a medium or smooth value between slow and fast. Authors could then react to the following capabilities:

• cannot update at all
• can update with noticeable delay
• updates fast enough to make human vision perceive continuous motion, but may flicker ≈ 10–40 Hz, covering classic frame rates for movies and TV
• will update as quickly as possible, beyond human perception

[schenney-chromium]

If this does move forward, I think the query should only trigger on things like battery state (i.e. transitional), not fundamental device characteristics. The latter would add yet another fingerprinting bit to media queries.

[tabatkins]

updates fast enough to make human vision perceive continuous motion, but may flicker ≈ 10–40 Hz, covering classic frame rates for movies and TV

What's the use-case for this division, though? What sort of animations should I decide to switch off or keep on, based on this category?

[frivoal]

I think we could (should) add to the spec's examples that the update: slow is expected to activate in situations where a device which is normally capable of update: fast is deliberately dialing down performance to conserve energy

[Crissov]

Since MQs are not only used with(in) CSS, but are also available in media attribute values or as part of others of some markup languages, particularly HTML 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:

<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 slowly 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 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.

PS: The spec already mentions “severely under-powered devices” as an example for slow. This could be improved like @frivoal suggests.