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