CSS dynamic-range-limit property

[ccameron-chromium]

WebKittens

@smfr

Title of the spec

CSS dynamic-range-limit

URL to the spec

https://github.com/ccameron-chromium/hdr-headroom-limit/blob/main/EXPLAINER.md

URL to the spec's repository

https://github.com/ccameron-chromium/hdr-headroom-limit/blob/main/EXPLAINER.md

Issue Tracker URL

No response

Explainer URL

No response

TAG Design Review URL

No response

Mozilla standards-positions issue URL

No response

WebKit Bugzilla URL

No response

Radar URL

No response

Description

This adds a CSS property to control the brightness of high dynamic range content.

It is very similar to UIImageView preferredImageDynamicRange API, in that it specifies qualitative HDR levels (standard, constrained-high, and high) that may be interpreted by the user agent to provide the best user experience, instead of quantitative HDR headroom values.

[annevk]

I don't see any abuse considerations. As a web developer it might be quite attractive to just specify

:root { dynamic-range-limit: high }

as why would you not want all your HDR images to look as good as possible.

cc @smfr @shallawa

[Ahmad-S792]

Web-Spec (in Draft) - https://drafts.csswg.org/css-color-hdr/#controlling-dynamic-range

Post - w3c/csswg-drafts#9074

[ariofrio]

In practice, the browser default behavior is already dynamic-range-limit: high on Chrome on macOS (user reports #1, #2), while it seems to be dynamic-range-limit: standard (or constrained-high?) on Safari on macOS (user report #1). I'm not sure what the current defaults on other platforms are.

From a power user point of view, I'd love to have a dynamic-range-limit CSS property like this so that I can install a Chrome extension to force standard or constrained-high on all websites, as rarely do I want to see videos at full HDR brightness alongside SDR content. Potentially, I'd like to whitelist some websites like Netflix that display HDR content on the whole screen.

On many websites with user-generated content, such as Amazon or Instagram, SDR content such as text look dim next to HDR images and videos. Additionally, scrolling past images and videos with HDR (these often appear in the reviews section of Amazon listings) causes the whole display to flicker light and dark and back again several times, audio stuttering, and responsiveness to suffer for about a second or two.

From a regular user's point of view, however, the browser default for this should probably be set to standard or constrained-high across browsers and platforms to make this the happy path.

As far as abuse:

1. Issue: Would developers find it attractive to just specify :root { dynamic-range-limit: high } to make all their HDR images look as good as possible?

   Counterargument: I'm not sure it's a safe assumption that HDR images next to SDR content actually look "as good as possible." In fact, it is quite jarring. I actually think it would be common and a good design practice to set dynamic-range-limit to standard or constrained-high on most websites, if it's not already the default in all browsers. (Some developers without access to HDR-capable displays and browsers might incorrectly set this to high without noticing a problem, though.) Especially for websites with user-generated content, they would prefer to disable the high setting to improve the experience of consumers of content.

2. Issue: Developers of ads and other embedded content may attempt to capture the user's attention, against the wishes of the host (surrounding) website developer, by using HDR content in an iframe (which would not inherit the value of dynamic-range-limit) or overriding the dynamic-range-limit property.

   Mitigation: Browsers could enforce this limit inside iframes, even if the CSS value itself doesn't propagate, and even if the content inside the iframe sets a higher dynamic-range-limit value. Developers would need to consider whether the code they embed without an iframe can be trusted not to display HDR content to capture the user's attention, but they already have to trust that code since it opens them up for many other security risks.

3. Issue: Rogue websites, or simply websites that depend on ad revenue, could display HDR content to capture the user's attention to attempt to improve click-through rates. (This is different from the previous issue in that the abuser is the host website developer, not the embedded content developer.)

   Mitigation: Perhaps honoring dynamic-range-limit: high should be opt-in, since it can be quite uncomfortable to unexpectedly see HDR content and is an accessibility concern (see next issue), similar to Webcam and Microphone permission dialogs in browsers. Alternatively, users can depend on browser features or third-party extensions to force dynamic-range-limit: standard or constrained-high on offending websites.

4. Issue: The way HDR content is implemented in Chrome and macOS causes rapid bright and dark flickering, which can trigger seizures in people with photosensitive epilepsy. Even for implementations that do not produce flickering, the contrast between SDR content and HDR content, especially unexpected bright HDR content, can be uncomfortable for people, especially those with sensory sensitivity (e.g. ADHD, PTSD, etc).

   Mitigation: Browsers can disable HDR content when prefers-reduced-motion: reduce (or some more specific media query related to flashing lights) if they are not able to implement HDR without flickering, as a stopgap measure to improve accessibility. The mitigations mentioned for issue (3) apply here too.

Another benefit of specifying behavior regarding HDR content in websites to the spec, whether through dynamic-range-limit or some other solution, is to help coordinate and communicate safe defaults across browser and platform developers.

[ccameron-chromium]

In practice, the browser default behavior is already dynamic-range-limit: high on Chrome on macOS (user reports #1, #2), while it seems to be dynamic-range-limit: standard (or constrained-high?) on Safari on macOS (user report #1). I'm not sure what the current defaults on other platforms are.

All browsers currently default to high for video elements.

With respect to image elements, HDR image support is absent except on Chromium (which has the effect that things look like standard). Implementing HDR image support is a bit harder than video, because, unlike video, images don't get their own compositing layer (at least most of the time).

From a power user point of view, I'd love to have a dynamic-range-limit CSS property like this so that I can install a Chrome extension to force standard or constrained-high on all websites, as rarely do I want to see videos at full HDR brightness alongside SDR content. Potentially, I'd like to whitelist some websites like Netflix that display HDR content on the whole screen.

Indeed there are some internal extensions doing exactly this.

On many websites with user-generated content, such as Amazon or Instagram, SDR content such as text look dim next to HDR images and videos.

HDR content that causes the eye to adjust like this is "bad HDR content".

A good discussion of responsible use of HDR is here. Most phone-captured images fit into these guidelines (of course there are sometimes failures, but they are more an exception).

I would argue that almost all phone-captured HDR video is currently "bad HDR content" (brighter but not better). The most recent version of macOS has started respecting the AMVE video tag, which causes iPhone-shot HDR video to be much less obtrusive. Chromium has also added AMVE support in Canary. We are also looking into further ways to encourage responsible HDR video.

Additionally, scrolling past images and videos with HDR (these often appear in the reviews section of Amazon listings) causes the whole display to flicker light and dark and back again several times, audio stuttering, and responsiveness to suffer for about a second or two.

This is a bug either in the OS or in the browser. The behavior has substantially improved in macOS Sequoia and recent Chromium updates.

As far as abuse:

There is a very analogous situation between HDR brightness and the volume of audio content. This is something that platforms have had to address at the content level. This has involved adjusting the volume of user-generated content to support a particular envelope (and also requiring that ads behave in this way). Fortunately, unlike audio, changing tabs will make obtrusive content go away.

[smfr]

I concur with many of the concerns listed in #312 (comment).

Looking at the spec draft, I am confused that this property is not inherited. Wouldn't you want it to affect all images in child nodes?

I am also not convinced that the default value for high is appropriate. constrained-high seems like a more reasonable default.

[ccameron-chromium]

I concur with many of the concerns listed in #312 (comment).

Looking at the spec draft, I am confused that this property is not inherited. Wouldn't you want it to affect all images in child nodes?

Yes, it should read "inherited". This is what the WPT tests expect, so it's just a matter of updating the spec to match the tests and implementation.

I am also not convinced that the default value for high is appropriate. constrained-high seems like a more reasonable default.

All browsers display HDR video using high as the default, so this would be a substantial change in existing behavior, which would require coordination with every site that delivers HDR video.

There does exist some HDR content that is "just too bright", and doesn't coexist well with SDR content at all. That's a "the content is bad" problem, and solving it via a default of constrained-high has the negative effect of further-enabling bad HDR content, and penalizing good HDR content.

BTW, an example of "bad extra-bright HDR content" is this video from this bug. An example of good HDR content (along with authorship recommendations) is this page. The HDR photos shot by iPhones and Pixel phones (and all other phones I've tried) are also quite well-behaved. So the momentum of capture is moving away from things like that bad example video.

[smfr]

We can't assume that web authors always have the best intentions; having high as the default leaves us open to antagonistic ads, for example.

[ccameron-chromium]

We can't assume that web authors always have the best intentions; having high as the default leaves us open to antagonistic ads, for example.

Yes, antagonizing ads can exploit HDR capabilities. This is already a potential issue. See this site for a (not-annoying) example of use of that capability.

In the original explainer, it's mentioned that:

A non-goal of this proposal is to provide a mechanism through which a maximum brightness of HDR content can be enforced on child elements of a given element.

Changing the default value will not solve this problem, because an ad that wishes to be excessively attention-grabbing can simply set dynamic-range-limit:high to get around the default value.

There are several things that browsers should consider pursuing, including:

• disabling or limiting HDR for cross-origin iframes
  • a "must explicitly allow HDR cross-origin" seems totally reasonable to me
• disabling or limiting HDR for "sufficiently backgrounded/occluded" windows (much like Preview does in Sequoia, though less aggressive)

But I think that these need to be separate APIs, because their behaviors ("force children" versus "set default that children inherit but can override") are quite different.

[svgeesus]

Looking at the spec draft, I am confused that this property is not inherited. Wouldn't you want it to affect all images in child nodes?

You are right, this was an error, fixed in w3c/csswg-drafts@b407f7a

I am also not convinced that the default value for high is appropriate. constrained-high seems like a more reasonable default.

I think you are right there also, but that is not what the spec says currently so raising an issue