- From: Chris Lilley via GitHub <noreply@w3.org>
- Date: Tue, 19 Aug 2025 14:32:03 +0000
- To: public-css-archive@w3.org
The CSS Working Group just [discussed](https://www.w3.org/2025/08/19-css-color-minutes.html#d624) `[css-color-hdr] auto value of dynamic-range-limit` <details><summary>The full IRC log of that discussion</summary> ccameron: Main question is what does this do <br> ccameron: one def works for me, other definition I'm allergic to<br> ccameron: Model we're converging to is, you get a value of headroom from display, then you plug that into tone-mappings, and that gets you a deterministic result<br> ccameron: all elements are impacted by this value the same way<br> ccameron: you can do limits on top of that<br> ccameron: what does 'auto' do?<br> ccameron: if auto maps to some hdr headroom value uniformly, so that two different videos get rendered with the same headroom, that's fine<br> ccameron: but if they get rendered with different headroom depending on [whatever], that's bad<br> ccameron: comment from April 2nd is basically this, is the auto here about using heuristics, or is browser using default value?<br> ccameron: Doesn't need to even need to map to one of the standard values<br> ccameron: but just be consistent across elements<br> ccameron: want it to be predictable behavior<br> ccameron: you could have a browser that examines content and decides headroom per page, but element-per-element is bad<br> ccameron: if this matches what WebKit might want to do, then fine to tighten up language around that<br> fantasai: can't rememeber where we landed on<br> fantasai: dont' think doing an element-by-element smapling makes sense<br> fantasai: you're right, two videos shoudl use the same<br> fantasai: i think the idea was less about customizing per element, and maybe about which html elements get different beheavior? or media types? something.<br> ChrisL: some discussions assumed video is always HDR and images are always not, but we changed that<br> fantasai: right, so i think some of the tweaking was from that perspective<br> fantasai: the other thing someone mentioned somewhere was, if something is fullscreen we give it full headroom; otherwise it's constrained<br> ccameron: i think that's compatible with what i'm dsicussing<br> ccameron: auto could map to constrained, but if there's a fullscreen the whole page gets more headroom<br> fantasai: so the whole fullscreen element gets more headroom, and the rest of the page does too (but probably not visible)<br> fantasai: i think tho that the apple people here at this hour don't have the context for<br> fantasai: but i think we could agree there shoudlnt' be a content-based heuristic per-element. everything should be whole-page<br> matthieud: so take back to the issue to make sure we have feedback from the right people<br> fantasai: but we should get input from the people who know what they're talking about<br> ccameron: you also disucssed a limited boost to HDR #10296, some people author their hdr badly<br> ccameron: common in HLG videos shot by phones, it just effectively makes your sccreen brighter without actually using the range. it's a tragedy, we're digging our way out of it.<br> TabAtkins: it doesn't sound like we can actually hit a resolution on anything yet. we'll take it back to the issue.<br> ChrisL: Sad that this is the fifth time we've gone back to the issue<br> fantasai: true, but we have advanced the discussion in this area since then, so unclear how this issue has morphed<br> ccameron: another future comment, hopefully at tpac - i have a spreadsheet of all hdr features, might be a good idea there to figure out where it fits in<br> -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11558#issuecomment-3201015197 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 19 August 2025 14:32:04 UTC