[csswg-drafts] [css-color-hdr] Alternative proposal for `dynamic-range-limit` defaults (#11711)

weinig has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-color-hdr] Alternative proposal for `dynamic-range-limit` defaults ==
With the new (to me) information that Safari does not currently render HDR images as HDR, I want to propose an alternative to the status quo where the initial value of `dynamic-range-limit` is `no-limit`.

I propose we change the initial value of `dynamic-range-limit` to `standard` and suggest an update to the default user agent style sheet of:

```css
video {
    dynamic-range-limit: no-limit;
}
```

This brings with it a number of benefits (and of course some tradeoffs).

The benefits are:
- Relatively easy to understand. The web has been mostly SDR for a while, and <video> is a bit of a special case where HDR has been for a while.
- Limits accidental HDR usage by authors who aren't testing in the latest browsers.
- Can simplify the story for HDR CSS colors by allowing us to define that when an author specifies `dynamic-range-limit: no-limit` or `dynamic-range-limit: constrained-high`, CSS colors can also participate, allowing `color(srgb 10 0 0)` (or what have you) be super bright (behaving like a non-gain-map style (non ISO 21496-1? I need a better term for this kind of image) HDR image. This wouldn't preclude the use introduction of an `color-hdr()` function [as proposed](https://github.com/w3c/csswg-drafts/issues/11616), as that would just end up being the equivalent of a gain-map / ISO 21496-1 style image.

There are two tradeoffs I can see:
- I believe Chrome does support HDR images in some capacity already, so this would be a change for them.
- CSS colors that happen to be on a video element (say, a border) that happen to require additional brightness may raise the brightness accidentally, but I expect this to be almost non-existent in practice.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11711 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 14 February 2025 18:15:11 UTC