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