[css-color-hdr] auto value of dynamic-range-limit

[shallawa]

A new value is needed to allow the user agent to dynamically change the brightness of the HDR video, image or canvas based on the page/screen content or the system conditions.

In WebKit, we're still discussing exactly when to allow various HDR limits, but it's clear that the used HDR limit will be a result of various factors, including user choice, system state (e.g. low power mode), and system policies around when full HDR is appropriate. To this end, we believe that we need an auto value, which should be the initial value. Generally we'll allow auto to result in constrained-high, with high in some specific circumstances like video fullscreen.

[smfr]

cc @ccameron-chromium

[ccameron-chromium]

It'll be good to discuss in person at the F2F (I'll be calling in though).

Yes, the actually used HDR limit is affected by lots of factors, and part of the goal with the standard, constrained-high, high division is to give the user agent the freedom to make these sorts of choices.

So in the example, suppose you have an XDR display with headroom 16x. There is an video that would actually use the full 16x headroom. The user agent is free to look at the layout of the page and say "I'm going to say that high actually means 4x, because of (various heuristics)". And if the user agent later sees that the video is fullscreen (or mostly-fullscreen) it san say "let's kick high up to mean 16x".

It sounds like there's another separate feature swirling around which is a signal to say "do whatever is possible to give the maximum available headroom, because I really want it". It vaguely reminds me of w3c/screen-wake-lock#129 (comment) ... but it's not quite the same. It's sort-of a permission issue because it's saying "discard your power preferences, etc".

[ccameron-chromium]

More thoughts to get down before the F2F:

I am negatively disposed to the idea of allowing the user agent to apply heuristics to adjust the HDR headroom of the page on an element-by-element basis (e.g, limiting HDR headroom for small img elements, but automatically increasing it for larger img elements that look like they're the "center of attention"). Such a specification would create unpredictable behavior and incompatibility between browsers.

Any user agent imposed HDR headroom limits must be applied to the page as a whole. These limits could be imposed because:

• power savings are desired
• system-wide display settings change
• the page is backgrounded (e.g, this video shows what Preview does, which is
• other user agent specific heuristics

[shallawa]

Any user agent imposed HDR headroom limits must be applied to the page as a whole.

I agree. The goals of the user agent heuristics should be focusing on saving power if needed and providing the best user experience with HDR and non HDR contents.

[css-meeting-bot]

The CSS Working Group just discussed [css-color-hdr] auto value of dynamic-range-limit.

The full IRC log of that discussion

<kbabbitt> smfr: this is about dynamic-range-limit
<kbabbitt> ... spec has 3 values currently
<kbabbitt> ... allow author control over how bright an hdr video or image will be
<kbabbitt> ... I think current default in spec is high
<kbabbitt> ... we have concerns about that
<kbabbitt> ... general concern is that we don't think we want to allow web content to get max hdr in all contexts
<kbabbitt> ... could be source of annoyance, e.g. high hdr ad
<kbabbitt> ... but there are uses such as photography
<kbabbitt> ... we think UA should have control
<kbabbitt> ... with result combination of author and user control
<kbabbitt> ... constrained in Safari in normal use case
<kbabbitt> ... but allow fullscreen video to be full HDR
<kbabbitt> ... we think there are case where UA should make choices
<ChrisL> initial value is indeed high https://drafts.csswg.org/css-color-hdr/#the-dynamic-range-limit-property
<kbabbitt> .... so there should be author vlue that specifies default
<kbabbitt> ... if specified, UA doesn't necessarily provide it, but its used as hint or suggestion to UA
<florian> q+
<astearns> ack bramus
<kbabbitt> ... not saying there should bec omplicate dheuristics
<kbabbitt> ... where UA should compute how much HDR an element gets based on surroundings
<kbabbitt> ... but rather fullscreen gets HDR, others don't
<astearns> ack florian
<ccameron> q
<kbabbitt> florian: sympathize with use case entirely
<kbabbitt> ... wonder if we can do it by doing less than what you suggest
<ChrisL> q+ ccameron
<kbabbitt> ... instead have ? be default
<kbabbitt> ... give room to UA to interpolate values
<kbabbitt> ... if Safar thinks full hdr is not reasonable behave as constrained instead
<kbabbitt> ... but still give author ability to start in constrained context
<kbabbitt> ... at this point I think auto kind of does the same as constrained anyway
<kbabbitt> smfr: I think that's a reasonable sugestion
<kbabbitt> ... question of what we consider author value to mean in CSS
<hober> qq+
<kbabbitt> ... I do feel it's slightly magical
<kbabbitt> florian: maybe auto ais a replacement name for constrained hdr
<kbabbitt> ... don't feel we need both
<kbabbitt> ... but maybe auto is a replacement
<kbabbitt> smfr: I do think we need to distinguish between no hdr and constrained hdr
<astearns> ack hober
<Zakim> hober, you wanted to react to florian
<kbabbitt> hober: I do prefer a distinct auto value vs changing default to constrained
<ChrisL> I don't think that auto and constrained-hdr are the same
<kbabbitt> ... because I can't predict future and don't know what a sensible default will be in 20 years
<weinig> q+
<kbabbitt> ... auto feels more future proof
<astearns> ack ccameron
<kbabbitt> ccameron: there's an issue of compat with behjavior that browsers currently ship
<kbabbitt> ... which is every browser supports hdr video today
<kbabbitt> ... and has for severaql years
<kbabbitt> ... all browsers provide no way to do anything but high right now
<smfr> q+
<kbabbitt> ... so to change that is to change the behavior of every application, every site that hosts hdr video
<kbabbitt> ... when we discussed this about a year ago, that seemed like a reason that we can't change this default behavior
<kbabbitt> ... that's why high was chosen
<kbabbitt> .. . if this were coming from a position of no hdr anywhere
<kbabbitt> ... id be fine with standard as default
<kbabbitt> ... and all hdr being opt in
<fantasai> so maybe 'auto' means 'constrained-high' except on videos where it means 'high'?
<kbabbitt> ... towards the topic of auto vs constrained high
<kbabbitt> ... a constraint that the author is specifying on top of ? will determine whats on page
<kbabbitt> ... right now it's acceptablef or UA to behave as smfr suggests
<kbabbitt> ... unless fullscreen video, UA restricts
<kbabbitt> ... that's acceptable and perhaps constrained-high and high might have only small difference
<kbabbitt> ... so I think there's an issue where this is about content not saying " I want this to be extra bright" but "this is defined to be in full brightness"
<kbabbitt> ... I want to pull it back and let UAs be free to do other things
<kbabbitt> ... if page goes background, lose HDR
<kbabbitt> ...battery saver. lose hdr
<kbabbitt> ... page says I don't have a lot of HDR content I want this to show up please don't restrict me might be a separate proposal
<kbabbitt> ... sympathetic to idea of approaching from different direction but time machines are in short supply
<kbabbitt> smfr: first one is about hdr video
<kbabbitt> ... and maintaining current behavior
<kbabbitt> .. we haven't ruled out constraining more
<kbabbitt> ... get feedback that hdr is annoying sometimes
<kbabbitt> ... and leads to more power usage
<kbabbitt> ... your other point was re: css property allowing author to impose additional constraints
<kbabbitt> ... I think it's easy to forget that in the values that's the case
<kbabbitt> ... maybe unconstrained value should be none instead of ?
<astearns> s/?/high/
<kbabbitt> ... maybe we should rethink name of properties and values so it's obvious author is imposing limits on UA
<kbabbitt> ... instead of high, make it none since theres no limit
<kbabbitt> ... maybe constrained should be medium
<astearns> ack weinig
<kbabbitt> weinig: to clarify: in your version of this, would expllicitlyu putting high on something actually change the behavior in non fullscreen?
<fantasai> I had texted "hdr: none | some | all" to smfr mostly as a joke...
<kbabbitt> .... yo mentioned default auto meaning high in non fullscreen, would that change anything?
<kbabbitt> smfr: ccameron just touched on this, I think we're getting confused on what this property means
<kbabbitt> ... ccameron said, maybe that would be a separate property, to ask for momre HDR
<kbabbitt> weinig: I'm asking, in your mental model, would high do anything for any element?
<kbabbitt> smfr: not sure we know yet
<fantasai> 'dynamic-range: normal | extended | high' ?
<kbabbitt> weinig: that's the confusing thing to me, it sounds like what you are trying to describe is an upper bound of headroom
<kbabbitt> ... in different scenarios
<kbabbitt> ... so i fullscreen one upper bound, not fullscreen another
<kbabbitt> ... but all that really means is high constrained terms are just relative
<fantasai> 'dynamic-range: small | medium | large'
<kbabbitt> smfr: yes they shift
<kbabbitt> weinig: which seems reasonable
<kbabbitt> ... tyring to semantically mark up what position is
<kbabbitt> ... ccameron explained in comment, you're tyring to say something wehre I think this should alwasy be HDR
<ccameron> q+
<fantasai> 'dynamic-range: low | medium | high'
<kbabbitt> .. this is something tha can be mixed in other context
<kbabbitt> ... this can never be HDR
<kbabbitt> ... not sure there' sanything in spec currently that would preclued UA from redefining based on context
<astearns> ack ccameron
<kbabbitt> ccameron: return to one thing, issu eof hdr content bein gbad
<kbabbitt> ... there are roughly 3 sources of hdr content
<fantasai> 'dynamic-range: local | limited | express' wait, no wrong scale...
<kbabbitt> ... still photos taken on recent phones
<kbabbitt> ... those photos genereally coexist well without limits
<kbabbitt> ... graded to look good next to SDR content
<kbabbitt> .. profesionally made video
<kbabbitt> .. that too coexists quite well
<kbabbitt> ... netflix and watch something doesn't need to be pulled down
<kbabbitt> ... one thing which is terrible which is hdr video shot on phone not a samsung
<kbabbitt> ... it's bad everywhere
<kbabbitt> ... it's just let's make everything 4x brighter and maybe people will like it
<kbabbitt> ... I can be draconian about it, given my druthers I would reinterpret that as SDR
<kbabbitt> ... some people took their SDR colors and made 4x as bright
<kbabbitt> ... we need to assume HDR content will not look like that
<kbabbitt> ... lot of work towards fixing user generated content
<kbabbitt> ...assumption needs to be that HDR coexists reasonably well except for one bad thing we're tyrin to stamp out
<kbabbitt> ... in terms of shifting down that's what I had in mind
<kbabbitt> ... could be that constrained-high and high become the same
<kbabbitt> ... sympathetic to idea of no limit
<kbabbitt> ... limit none sgmt
<weinig> q+
<kbabbitt> ... in that case it sounds like we're ... how would you feel about changing name to be more accurate
<kbabbitt> ... and then starting discussion sabout page giving hints to UA
<fantasai> 'dynamic-range: standard | auto | unlimited'
<kbabbitt> ... because UA is going to do all sorts of stuff
<kbabbitt> ... so we might just stick with that for now and see if UAs implement hweuristics they want more input on
<kbabbitt> smfr: im happy with that
<kbabbitt> ccameron: suggestion for middle thing?
<astearns> ack smfr
<astearns> ack weinig
<fantasai> 'dynamic-range: standard | auto | high'
<kbabbitt> weinig: it would be great if instead of ... wherever we come up with default, instead use UA stylesheet to only apply to video and image
<kbabbitt> ... where it's actually required
<fantasai> 'dynamic-range: standard | extended | high'
<kbabbitt> ... we don't have a agoo under standing of what HDR conytrast values mean outside of those contrasts
<ccameron> q+ ... do we have a moment to discuss the topic of HDR colors
<ccameron> https://github.com//issues/11616
<kbabbitt> ... we don't currently have headroom for CSS values even if they have lots of brightness
<kbabbitt> ... finding some way to constrain this property to things it applies do
<kbabbitt> s/do/to
<ChrisL> we currently have headroom==0 for css colors (SDR)
<kbabbitt> astearns: would it make sense to have an hdr only breakout session in next week or tow?
<kbabbitt> ChrisL: I think so especially since there's a new issue from ccameron
<kbabbitt> ... which actually addresses directly that
<kbabbitt> ... how to get CSS colors in HDR
<kbabbitt> ... it would be great to have more tie on these isseus
<schenney> Background images?
<kbabbitt> ... nicely themed breakout, in favor
<kbabbitt> astearns: if we do that, can we take this back to the issue for now and have this be part of agenda for breakout?
<kbabbitt> [agreement]
<kbabbitt> astearns: let's do that, email me if you'd like to be part of breakout session

[ccameron-chromium]

From the F2F discussion, it sounds that there is consensus that we should change the name of high to none, because it is representing "no limit".

Should we change the names of the other limits? What about constrained (instead of constrained-high) and keep standard?

[svgeesus]

If we change high to none then constrained (instead of constrained-high) would seem the consistent change.

[smfr]

Did we decide on the "scaling" behavior? If the UA decides that a page is constrained overall, does content with constrained render at a lower brightness as none, or the same?

[svgeesus]

Did we decide on the "scaling" behavior? If the UA decides that a page is constrained overall, does content with constrained render at a lower brightness as none, or the same?

We didn't decide, I think; but that is a good question and my weak preference is that it is scaled down.

[smfr]

Would no-limit rather than none make it clearer? Or is it repeating a mistake we made with background-repeat: no-repeat?

[ccameron-chromium]

Did we decide on the "scaling" behavior? If the UA decides that a page is constrained overall, does content with constrained render at a lower brightness as none, or the same?

We didn't decide, I think; but that is a good question and my weak preference is that it is scaled down.

I think it's okay for the spec to not indicate that scaling is required, at least for now. When the UA or device headroom is very low (like <2), the difference will be hard to see. My weak preference is to not require scaling, at least not yet.

If we want to require scaling, we could indicate that by saying "if the HDR headroom of standard is strictly less than the HDR headroom of none, then the HDR headroom of constrained must be strictly between the two".

[ccameron-chromium]

Would no-limit rather than none make it clearer?

To add to the menu of options:
A: none, constrained, standard
B: no-limit, constrained, limit-to-standard
C: no-limit, limited, limit-to-standard

The no-limit does sound like something from Rounders...

Or is it repeating a mistake we made with background-repeat: no-repeat?

That seems fine to me (I wouldn't call it a mistake).

O(1) other thing was the discussion about what elements this applies to. I advocate this apply to everything. For image and video it has a clear meaning. For canvas it will soon (there is work to make that mirror the non-gainmap HDR images). For CSS colors, I think it will be liberating to impose the constraint that HDR-ness will be headroom parameterized and will default to SDR in some scheme approximating this.

[smfr]

Re: scaling. I don't think we should do scaling at a the level of the CSS cascade (i.e. a constrained inside a constrained should not be more constrained). So all the constrained in a "browsing context" (used loosely) would get the same headroom.

But at an OS level, the OS might change the tone mapping of an entire window, which would effectively do scaling. For example, when the UA is put in the background, the window's available headroom may be constrained. But that's independent of any CSS-level behavior.

[ccameron-chromium]

I don't think we should do scaling at a the level of the CSS cascade (i.e. a constrained inside a constrained should not be more constrained)

+1. Sorry if I didn't clearly communicate that earlier -- I hadn't understood the question. Indeed, you can do something like "create a gallery div with constrained, and then let a single element within the div be no-limit.

[shallawa]

For the names of the values, I filed #11698

[shallawa]

I don't think we should do scaling at a the level of the CSS cascade (i.e. a constrained inside a constrained should not be more constrained)

+1. I think this is true for other CSS properties also. Having font-weight: bold; applied at different levels of the CSS cascade does not make the text in an element bolder than its ancestors.