[css-color-hdr] New values for dynamic-range-limit property

[shallawa]

The current draft https://drafts.csswg.org/css-color-hdr/#the-dynamic-range-limit-property suggests the following values for this property:

standard | high | constrained-high | <dynamic-range-limit-mix()>

With the suffix limit at the end of the name, these values can be a little confusing.

1. Does the value high mean the dynamic-range is high?
2. Or does high mean the limit on the dynamic-range is high?

These options are proposed in the F2F meeting and here #11558 (comment) as well.

1. none, constrained, standard
2. no-limit, constrained, limit-to-standard
3. no-limit, limited, limit-to-standard

[css-meeting-bot]

The CSS Working Group just discussed [css-color-hdr] New values for dynamic-range-limit property, and agreed to the following:

• RESOLVED: change high to no-limit

The full IRC log of that discussion

<joshtumath> s/as proposal/as note/
<joshtumath> said: the current value for dynamic-range-limit is 'high'
<joshtumath> ... we believe UA may want more control based on system conditions
<weinig> q+
<ccameron> q+
<joshtumath> ... we propose value of auto to pick properties from system
<joshtumath> astearns: there was an issue on auto. I thought you wanted to discuss other values first
<weinig> q-
<joshtumath> said: if we're talking about names, this property name is confusing
<joshtumath> ... if we look at dynamic range, 0 is r.
<joshtumath> ... dynamic range also is ????
<joshtumath> ... high is full brightness, 0 is 0 brightness
<joshtumath> ... I think we should change the names of values to show it's in the negative side and limit the ??? of the video
<joshtumath> ... is high high dynamic range or high limit on dynamic range
<joshtumath> ... suggestion of 'none'
<joshtumath> ... I think this is better than existing one
<joshtumath> smfr: or 'constrained'
<smfr> s/constrained/unconstrained/
<joshtumath> ccameron: I wrote the names and with discussion I agree they only make sense if you already know what they're doing
<joshtumath> ... I gave three options at F2F that ephasise these are the limits the author is placing
<joshtumath> ... so how do you say that the page doesn't want to limit itself?
<joshtumath> ... I agree 'high' is not intuitive
<joshtumath> ... so I am flexible on these terms
<astearns> q?
<joshtumath> ... I feel unable to give honest assessment. I was hoping we could vote or something
<joshtumath> ... issues like auto value come from how these proposed values are uncomfortable
<joshtumath> astearns: I prefer no-limit
<joshtumath> smfr: like background: no-repeat!
<joshtumath> ChrisL: I like no-limit as well
<joshtumath> astearns: should we resolve on that with option to bikeshed later?
<joshtumath> ChrisL: three values: you want SDR, as much HDR as you get and 'don't go overboard'
<joshtumath> ?????: could it be 'default'?
<joshtumath> smfr: only one browser has shipped this
<astearns> s/?????/nicole/
<joshtumath> ccameron: everyone serving HDR video will get a surprise if we change the default behaviour
<joshtumath> ccameron: not shipped yet
<joshtumath> ChrisL: just saying with no property specified, what do you get?
<joshtumath> smfr: I think we decided at F2F it should be about limiting. less HDR than what the UA could give
<ccameron> also pre-ramping in HDR headroom
<joshtumath> ... but maybe you want in an image editor on the web to say full HDR
<joshtumath> ... so the OS will constrain how much HDR allowed. and UA. constraints may differ depending on in full screen
<joshtumath> ... can you say 'go away constraint. I want HDR'
<ChrisL> q+
<ccameron> q+
<astearns> ack ccameron
<astearns> ack ChrisL
<astearns> q+ ccameron
<joshtumath> ChrisL: if you have one prop to limit it to less, and another to get more, how do you explain that?
<weinig> q+
<joshtumath> ... I'd rather one prop that gives you the full range. sounds like an auto value to me
<joshtumath> ... but I want to express give me it all or tone it down
<joshtumath> ... and it should be on the same property
<astearns> ack ccameron
<joshtumath> ccameron: the idea of saying I want all the HDR. would you set that on an element?
<joshtumath> ... you're saying 'hey wrap things up'
<joshtumath> ... one thing is when you think you're going in a certain headroom at some point in the future, so you could set the headroom early to get the effect
<joshtumath> ... or 'I know my page will use headroom 5'
<joshtumath> ... I view that as a hint to the OS of what to do. and asking for permission
<smfr> q+
<joshtumath> ... the OS may want to revoke that
<joshtumath> ... my feeling about the ramping, it's not something-- if we attach it to an element, it's not been great
<joshtumath> smfr: That makes sense
<joshtumath> ... it's like the wait lock API
<joshtumath> ... so the property we're talking about is only a limiting property
<astearns> ack weinig
<joshtumath> weinig: smfr came to my conclusion
<joshtumath> ChrisL: and I'm on the same page now as well
<astearns> ack smfr
<joshtumath> smfr: I think we can get back to bikeshedding
<joshtumath> weinig: but auto vs high. I think the default of high or no-limit is good
<joshtumath> ... everything is inherently 'auto'
<smfr> q+
<joshtumath> ... you say 'I don't need the system to do it'
<joshtumath> ... that's a strong thing. you don't want to put in effort to make sure images are non HDR
<joshtumath> ... you're saying there may be HDR pixels in there but ignore them
<joshtumath> ... existing concept of defaulting to 'do what you do' and then let the user ramp it down
<astearns> ack smfr
<joshtumath> smfr: I think there are legacy reason why auto might make more sense
<joshtumath> ... historically we've allowed video to be high, but we might not want that for images
<joshtumath> weinig: do images not have high today?
<joshtumath> smfr: we don't have HDR support in mobile safari
<joshtumath> ... we want to avoid the HDR in the corner of your eye problem
<joshtumath> weinig: you want to avoid accidental HDR? not annoying the user, the user could put 'high' on themselves
<joshtumath> ... I don't think having an annoyance as a blocker is going to be effective. you could make an accidental prevention thing at best
<astearns> q+
<joshtumath> ccameron: I worry about the auto thing being a way to opt into a quirk
<joshtumath> ... I prefer no limit as a default and the UA performs heuristics to make sure HDR is limited by default
<joshtumath> ... if a video occpuies x % of pixel area, you let the image shine through
<joshtumath> ... I think what limit is imposed by the UA needs to be imposed on ????? together
<joshtumath> ... that I think will come back and hurt us
<pal> q+
<smfr> q+
<astearns> q- later
<joshtumath> ... I think best resolution is to say for now, do heuristics for video, etc, and then the permission for headroom could be something we let pages start doing
<joshtumath> ... I think the opt out option is introducing an inconsistency to the model that will tear itself apart
<joshtumath> ... there is a continuum of pages that the author has specified
<joshtumath> ... so basically you specify that and the author says 'I'm outside of that continuum'
<joshtumath> ... I think it will cause compatibility issues
<weinig> q+
<joshtumath> ... I think of it like: a heuristic about the UA is how I'd like to accomplish that
<astearns> ack smfr
<joshtumath> smfr: ccameron said he would like the limits on the whole page, but we can't do that because of the legacy video HDR issue
<astearns> ack pal
<astearns> q- later
<ccameron> +1
<joshtumath> pal: I think having the UA police obnoxious content is ??. It's up to the author to make a page make sense
<joshtumath> ... if you don't want an obnoxious ad, don't let them on the page
<ccameron> and to amplify pal's comment, if we auto-limit things too much, then authors will get used to creating too-bright content
<joshtumath> ... it's too late for the UA to deal with it
<astearns> ack weinig
<joshtumath> weinig: one other option is to think about this from UA stylesheet perspective.
<joshtumath> ... is there a model where img elements get standard or whatever as default. video gets high as default.
<joshtumath> ... there are probably some version of this where concept is still there but reasonable defaults for UA stylesheet
<smfr> q+
<astearns> q- later
<joshtumath> ... doesn't help people using HDR background image, though
<joshtumath> ... someone could still accidentally have a HDR background image
<astearns> zakim, close queue
<Zakim> ok, astearns, the speaker queue is closed
<joshtumath> said: I think you mentioned we should fall back to no limit
<joshtumath> ... but I think opposite. no limit is like auto
<joshtumath> ... some blind heuristics will not be able to do it the same way
<joshtumath> astearns: all of this is intertwined. all the issues.
<joshtumath> ... we need to make decisions on these three issues. I don't think there's anything where we can say this is the output of the meeting
<joshtumath> ccameron: I agree we haven't resolved. I thought at the F2F we agreed auto is not needed
<joshtumath> ... It sounds like that wasn't where we got to
<joshtumath> ... names is close to resolution. auto still remains no consensus
<joshtumath> astearns: can we resolve to change high to no-limit?
<joshtumath> PROPOSED RESOLUTION: change high to no-limit
<joshtumath> RESOLVED: change high to no-limit
<pal> Thanks for the super clear agenda
<joshtumath> astearns: I thought this conversation was useful. meet again in two weeks?
<ccameron> O(1) more thing

[svgeesus]

Resolution applied, leaving issue open in case we need to re-bikeshed other values

[ccameron-chromium]

Of note is that, when originally created, the idea was to line up with dynamic-range media query (hence high and standard, which line up with those values).

I'd like to add an "option 4" below, which replaces limit-to-standard with just standard, to be less verbose. I personally prefer 2 & 4 of the options. My preference between those two options vacillates.

1. none, constrained, standard
2. no-limit, constrained, limit-to-standard
3. no-limit, limited, limit-to-standard
4. no-limit, constrained, standard

Any further thoughts (or just votes)?

[svgeesus]

The spec now has no-limit, and I like constrained and standard as the other two values.

[fantasai]

constrained vs standard -- it's hard to understand which is more limited from those two names.

My suggestion would be something like dynamic-range: standard | expanded | no-limit or dynamic-range: standard | wider | no-limit or something

[Crissov]

Unless self-referential, ”standard“ almost always seems like a bad choice within a standard, because standards change.

[svgeesus]

In general yes, but the retronym "Standard Dynamic Range (SDR)" as the alternative to "High Dynamic Range (HDR)" is well established, so aligning to the current terminology seems correct

[css-meeting-bot]

The CSS Working Group just discussed [css-color-hdr] New values for dynamic-range-limit property.

The full IRC log of that discussion

<astearns> ack ChrisL
<fantasai> Suggestions from ccameron at https://github.com//issues/11698#issuecomment-2662695204
<weinig> fantasai: its not clear that constrained is less constrained than standard
<weinig> ccameron: standard lines up with the media query, meaning most locked down
<fantasai> ccameron: Standard lines up with terminology and media query
<fantasai> ccameron: no-limit is pretty clear
<fantasai> ccameron: Do we agree on the two end points?
<fantasai> ChrisL: Yeah, it's just the middle one
<fantasai> ccameron: Constrained seems great to me, but I've been deep in this for a long time
<weinig> fantasai: maybe we can resolve on standard and no-limit, and ask the rest of the wg on names
<weinig> ChrisL: we already are pretty resolved on standard and limit
<weinig> s/limit/no-limit/
<weinig> fantasai: asking a person if constrained or standard is more constrained...
<weinig> https://github.com//issues/11307#issuecomment-2718858571

[jensimmons]

@svgeesus Could you update the spec with the most recent correct value names? Best I can tell, the spec is wrong and Can I Use is correct?? That's an odd place to be.

[svgeesus]

@jensimmons sorry but could you explain what is wrong in the spec?

RESOLVED: change high to no-limit

That was done in #11698

<weinig> fantasai: maybe we can resolve on standard and no-limit, and ask the rest of the wg on names
<weinig> ChrisL: we already are pretty resolved on standard and no-limit

Not an actual resolution, but the spec does have standard and no-limit and as the minutes say, the other name is up in the air.

Value:	standard | no-limit | constrained-high | <dynamic-range-limit-mix()>
Initial:	no-limit

Several people proposed constrained rather than constrained-high and I said I preferred it, and @fantasai said she did not.

We have Agenda+ so hope we can resolve on constrained

[jensimmons]

Thank you @svgeesus, that's really helpful. I also hope we can put this on the agenda for very soon.

[svgeesus]

For this weeks call, the proposed resolution is

Value:	standard | no-limit | constrained | <dynamic-range-limit-mix()>
Initial:	no-limit