- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Mar 2025 19:56:35 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-color-hdr] Initial value of `dynamic-range-limit` ``. <details><summary>The full IRC log of that discussion</summary> <fantasai> ccameron: should it be auto or no-limit?<br> <fantasai> ccameron: I'm sympathetic to idea that if we're doing this ex-novo, make HDR opt in and whatever for the default<br> <fantasai> ccameron: but given every browser is shipping HDR on video by default<br> <fantasai> ccameron: and HDR images is not implemented yet only due to technical complexity<br> <fantasai> ccameron: I think UA should pull down everything together, and e.g. UA limits to 2x and you have to hint that you want HDR to get it<br> <fantasai> ccameron: or have mode where try to be smart in that property<br> <weinig> q+<br> <fantasai> ccameron: right now UA can do anything<br> <fantasai> ccameron: But I think everything should be limited on a page together<br> <fantasai> ccameron: if global limit, then adjust<br> <fantasai> ccameron: if there's behavior we want to care about<br> <fantasai> ccameron: better to let HDR images shine out, if too bright, that's just bad content<br> <fantasai> ccameron: clear signal that your HDR content is not authored in a good way<br> <fantasai> ccameron: we want people to integrate in a good way<br> <fantasai> ccameron: encourage people to create good content<br> <fantasai> ChrisL: I tend to agree with that<br> <fantasai> ChrisL: e.g. you could create lime green with flashing gif<br> <ccameron> I haven't been to Geocities that recently....<br> <fantasai> ChrisL: we don't limit that<br> <astearns> ack weinig<br> <fantasai> weinig: piece we're missing is, what's the goal of this property?<br> <fantasai> weinig: establish goal, then we can figure out our values<br> <fantasai> weinig: but without that, it's hard for us to make smart decisions<br> <fantasai> weinig: general premise of protecting people from poorly designed website is not our battle<br> <fantasai> weinig: But author may not know the source of images, so having author's abilitiy to limit<br> <fantasai> weinig: in this index, we're going to constrain HDR, because we dont' know what they contain<br> <fantasai> weinig: let's not waste that power<br> <fantasai> weinig: but default should be no limit, no use case for auto<br> <weinig> fantasai: believes that WebKit's position was that the initial value should be constrained<br> <weinig> fantasai: and things on a case by case basis should be marked unconstrained by authors<br> <weinig> fantasai: unfortunately not sure of the details, smfr would know more<br> <weinig> fantasai: authors do have the issue of things like 3rd party content, ads,<br> <ccameron> q+<br> <weinig> fantasai: if the default is no-limit, those ads might do bad things, and they would not know, because things works fine now<br> <astearns> ack fantasai<br> <fantasai> ads or user-generated content<br> <astearns> ack ccameron<br> <weinig> ccameron: would it be better to have a global hint?<br> <weinig> ccameron: we have to deal with the fact that video is already not constrained today<br> <weinig> ccameron: lots of people count on that<br> <weinig> fantasai: webkit/apple thinks a ua style sheet for video would help<br> <fantasai> ccameron: some browsers are shipping HDR images already, would break that behavior<br> <weinig> ccameron: for chrome, this would break things for images and webgpu canvas, which have already shipped<br> <fantasai> ccameron: hard to explain why we have this default a few years from now<br> <fantasai> ccameron: why not have a global signal<br> <fantasai> ccameron: whole page, if you want to keep the old behaviors, you need to opt into it<br> <fantasai> ccameron: roll that out slowly later<br> <fantasai> weinig: 2 weeks ago, position was that webkit/apple really wanted images also to be HDR unconstrained<br> <fantasai> weinig: in addition to video<br> <fantasai> fantasai: I can't remember which elements were proposed to except. ^_^;;<br> <fantasai> weinig: What if we split property in two, and have one limit apply to things like video/image/canvas -- replaced content<br> <fantasai> weinig: and separate one that applies to CSS colors etc.<br> <fantasai> weinig: then you could decide... is bg one or the other<br> <Said> q+<br> <astearns> ack Said<br> <fantasai> Said: I've been working with HDR for awhile now, and I feel it is really distracting to see HDR and SDR together in the same page<br> <fantasai> Said: I tried to get high quality HDR, but still same experience<br> <fantasai> Said: So it makes sense to me, to always have mixed content always be constrained<br> <ccameron> q+<br> <astearns> q+<br> <fantasai> Said: and only allow no-limit for fullscreen(?)<br> <astearns> ack ccameron<br> <fantasai> Said: This is my experience with SDR and HDR in the same page<br> <fantasai> ccameron: Right now the UA is free to do that, to limit all the HDR in the page to nothing for e.g. background windows (like Preview does on MacOS)<br> <fantasai> ccameron: and they can also limit the range heuristically, based on outlines<br> <fantasai> ccameron: Key thing is that the limit is imposed by UA on all content, so that page is affected all together, not element by element<br> <fantasai> ccameron: dynamic-range-limit property is author saying what they wayt<br> <fantasai> ccameron: if UA wants to do something beyond that, is compatible<br> <Said> q+<br> <fantasai> ccameron: Sympathetic to opt-in idea, but given where we are, disagree.<br> <fantasai> astearns: Wrt separate properties idea, aside from images and video, you can define a bg color as HDR color<br> <fantasai> astearns: if we decide initial value of dynamic-range-limit is constrained, then it's double-opt-in for that color? You'd have to specify the color and also raise the limit<br> <fantasai> ChrisL: You'd still get the color, just a more subdued color<br> <fantasai> astearns: That's a fair argument for not having a constraint, since we tend to avoid double opt in<br> <ChrisL> s/the color/an HDR color<br> <fantasai> weinig: We would re-imagine existing CSS colors as all being HDR capable, as long as their components were large enough<br> <astearns> ack fantasai<br> <fantasai> weinig: it wouldn't be a double opt in, you just need a color bright enough to warrant using some headroom<br> <astearns> ack astearns<br> <weinig> fantasai: the idea that the UA can do anything it wants<br> <weinig> fantasai: works well in cases where the UA has the final say, like background window<br> <weinig> fantasai: but it doesn't work well when the author overriding things<br> <weinig> fantasai: in that case, a property makes sense<br> <weinig> fantasai: element by element makes sense<br> <weinig> fantasai: but a different default for fullscreen or loaded alone might make sense<br> <weinig> fantasai: but allowing a page to have a mix of HDR and non-HDR might make sense too<br> <weinig> fantasai: like YouTube, where there is video, but also other content<br> <weinig> fantasai: but only the main video should be HDR<br> <weinig> fantasai: magic limits later seems worse<br> <weinig> fantasai: should figure this out now, and make it work with the cascade<br> <weinig> fantasai: weird huerstics are worse, viewport metatag is awful<br> <astearns> q+<br> <astearns> ack Said<br> <fantasai> Said: We should take consideration the default, any possible auto values, take into consideration the transition<br> <fantasai> Said: At this time [missed]<br> <fantasai> Said: For example eBay, suppose someone decided "well, now all browsers support HDR, let's use this ability"<br> <fantasai> Said: [missed2]<br> <fantasai> astearns: I'm not sure I understand the story of having a constrained default be useful if we are also specifying that videos and images are not constrained for compat reasons<br> <fantasai> astearns: story of page with a lot of videos, if videos have their headroom expanded in UA stylesheet, that default is doing nothing for that case<br> <astearns> ack astearns<br> <fantasai> weinig: We have to figure out and agree on our goal<br> <fantasai> weinig: sounds like we dont' quite agree on it<br> <ccameron> q+<br> <fantasai> weinig: is the goal that videos, images are constrained or unconstrained? constrained in some circumstances? browsers can have different goals?<br> <fantasai> weinig: I see different goals here. We need to converge on the goal.<br> <fantasai> weinig: Another issue is that chrome has shipped this, so we also potentially have a compat problem here<br> <fantasai> weinig: Maybe Apple can give a concerete proposal<br> <fantasai> s/concerete/concrete/<br> <fantasai> Said: My understanding is that we like to provide the nicest experience for the user even during the transition period<br> <fantasai> Said: Having HDR without constraint doesn't seem nice<br> <fantasai> Said: so we want the default to be constrained-high for images<br> <astearns> ack ccameron<br> <fantasai> ccameron: One of my goals is to not lull people into the idea that they have good content because it looks good by default<br> <fantasai> ccameron: I want to show exactly what was specified up to capabilities of the machine<br> <fantasai> ccameron: and hope this will inform people to make good choices about how they use HDR<br> <Said> q+<br> <fantasai> ccameron: if specify too much, and end up getting 2x as bright because ...<br> <fantasai> ccameron: There is concern that I'm authoring to 10, but not knowing it<br> <fantasai> ccameron: HDR video authored with PQ is usually quite good.<br> <fantasai> ccameron: HDR images on iPhone, Pixel, etc are also good. They don't blow your eyes out.<br> <fantasai> ccameron: But ?? video shot at iPhone and Pixel is way too bright, looks bad, ruins people's eyes<br> <fantasai> ccameron: problem with that is, people were allowed to create the content without seeing what they're specifying<br> <fantasai> ccameron: I think it's better to show what was specified, and hope they are not making it unpleasant to view<br> <fantasai> ccameron: Should it turn out that we're wrong, and ppl can't do this right even when seeing what they're producing, then maybe ratchet down the defaults or global switch or something<br> <fantasai> ccameron: If we limit things by default, they will create bad content because won't see what they're specifying<br> <fantasai> ccameron: I want to give ecosystem a chance to get it right<br> <fantasai> ccameron: otherwise will be bad forever<br> <astearns> ack Said<br> <fantasai> Said: I disagree with ccameron<br> <fantasai> Said: Here's an example<br> <fantasai> Said: In WebKit, we limit animation to 60fps. But in Chrome, it uses device frame rate<br> <fantasai> Said: Chrome has already hit a problem where the frame rate can be 200 or 500, some device has this kind of speed<br> <fantasai> Said: and Chrome can't cope with this speed, and begins to limit it<br> <fantasai> Said: So I think unlimited would give you a bad experience<br> <astearns> ack fantasai<br> <fantasai> Said: We want to give the normal user the best experience.<br> <weinig> fantasai: Chris is making the argument we should give the author the opportunity to get it right<br> <weinig> fantasai: I am making the argument that there is a bunch of content out there where the author is not going to know, and user will get annoyed<br> <weinig> fantasai: not just about the transition period<br> <weinig> fantasai: constrained is a better default for the web<br> <weinig> fantasai: sophisticated authors will get it right<br> <weinig> fantasai: but many won't know how to make things right<br> <weinig> fantasai: better to make things opt in<br> <weinig> fantasai: you should not need to learn everything to use CSS<br> <ccameron> q+<br> <weinig> fantasai: shouldn't have to learn to turn down the headroom<br> <weinig> astearns: could be argued in either way<br> <astearns> ack ccameron<br> <weinig> astearns: could be hard to figure out how to make your photos look right<br> <fantasai> fantasai: If you want extra brightness you're expecting but not getting, then you can go looking for how to do it.<br> <fantasai> fantasai: but if your page is tacky and uncomfortable, as someone who isn't a designer, you might not even know why or that it's fixable<br> <fantasai> ccameron: I'm sympathetic to that argument, but in that case I would suggest a default of SDR<br> <fantasai> ccameron: since constrained high is [missed3]<br> <fantasai> ccameron: I could go for that. And maybe there's a bridge to that somehow.<br> <fantasai> ccameron: Keep going back to global thing.<br> <weinig> q+<br> <fantasai> ccameron: (something about gainmaps)<br> <astearns> ack weinig<br> <fantasai> ccameron: even if you have a very small headroom<br> <fantasai> weinig: I do think that the ideal default would be SDR<br> <fantasai> weinig: I would ask the browser vendors if that is a possibility, even though it would make some content that currently works not do what is expected<br> <fantasai> weinig: majority of content that wants to benefit from HDR values will learn about these properties<br> <fantasai> weinig: and in time get those properties set on them<br> <ccameron> q+<br> <fantasai> weinig: whereas if we start with unconstrained or a middle ground, it will always be fighting one battle or the other<br> <fantasai> weinig: both argument fantasai made and astearns made, that each group won't get behavior that makes sense<br> <fantasai> weinig: it would take video that's already HDR and make it not<br> <fantasai> weinig: but maybe that's OK<br> <fantasai> weinig: maybe there aren't enough websites that having this blip of compatibility isn't doable<br> <astearns> ack ccameron<br> <fantasai> ccameron: In terms of video, one difficulty is that right now tone-mapping videos to SDR is to do terrible and undefined things to the video<br> <fantasai> ccameron: One of the nice things about images is that, from the moment they were defined in terms of SDR and in HDR, its' all parameterized in terms of headroom and it's great<br> <fantasai> ccameron: but for video, don't have that<br> <fantasai> ccameron: in many cases no ability to even tell the OS to render under constraints<br> <fantasai> ccameron: so that limits what we can do for video. Even if we want to, in some OSes it is technically impossible<br> <fantasai> ccameron: I do horrible things to make it "work" in Chrome<br> <fantasai> ccameron: We're working on standards to improve the situation<br> <fantasai> ccameron: There's work going on in standards to improve video, to have double-graded content<br> <fantasai> ccameron: but for right now.... it would be a big amount of work<br> <fantasai> ccameron: and it yes, there are pages that serve HDR content, usually professional stuff and they are paying for the bandwidth<br> <fantasai> ccameron: I think there's a chance we could push in a different direction in the future, but really built in right now<br> <fantasai> ccameron: Can we switch topic to names?<br> <fantasai> ChrisL: +1<br> <fantasai> astearns: I wonder if we can decide on an sdr default with video override in the UA stylesheet<br> <fantasai> weinig: I think we really need Simon for that<br> <fantasai> weinig: since I proposed that last time, and he had objected<br> <fantasai> astearns: OK, we'll take that back to the issue for now<br> <ChrisL> q+<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11429#issuecomment-2718954138 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 March 2025 19:56:36 UTC