- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 Mar 2025 19:53:10 +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> <annevk> scribe: annevk<br> <annevk> smfr: We'd like HDR to be constrained by default, including images, but excluding videos as they have been the exception for a long time. Web developers get to opt-in to no-limit through CSS.<br> <annevk> smfr: We only want to give video content no-limit access by default, not video element border colors and such.<br> <annevk> smfr: We'd also want to limit cross-origin documents by default, excluding videos again. And we'd use a sandbox flag [editor: Permissions Policy] to let the embedder enable that after all.<br> <annevk> weinig: I think this makes it hard-if-not-impossible for content producers to match colors.<br> <annevk> ccameron: As a moral position, there are good arguments for any of the defaults. I'll agree with everything at some level. Do we consider it acceptable for different element types to have different default behaviors? I would not want that to be in the specification.<br> <annevk> ccameron: In another collaboration we very much try to make images and videos to behave the same.<br> <annevk> ccameron: Does constrained-high work with CoreAnimation? I think I have to use a shader.<br> <annevk> smfr: I don't think we can change the HDR behavior of YouTube. And I don't think we can ship no-limit by default as it'll look weird.<br> <annevk> weinig: There are not that many websites. Can we get the websites fixed?<br> <annevk> smfr: It's the embedding pages that would have to set the Permissions Policy.<br> <annevk> weinig: What's the goal of doing that?<br> <annevk> smfr: To prevent abuse essentially.<br> <annevk> weinig: I suspect ads will just abuse video.<br> <annevk> smfr: Seems harder to deploy.<br> <annevk> weinig/ccameron: People will do it if they want it.<br> <annevk> ccameron: I don't think images need to be constrained. Most of the photos look fine on a white background. HDR video content also seems mostly reasonable and is written to co-exist.<br> <annevk> ccameron: Also, even with constrained there can be bad content.<br> <annevk> ccameron: The path I thought might be reasonable: the unset default value is implementation-defined, ideally the same across all types. And then we regroup in a year and agree on a default.<br> <annevk> smfr: I'm sympathetic to the argument that "valid" HDR will get better. I'm worried about antagonistic HDR.<br> <annevk> ccameron: That's why I have thought about making standard the default and you'd have to opt-in.<br> <annevk> weinig: And then you'd require Permissions Policy for cross-origin documents too.<br> <annevk> ccameron: antagonistic HDR already exists, I've been assigned bugs.<br> <annevk> ccameron: for instance, a green screen background that hides content between sRGB and P3 green so only end users with a P3 screen see it (and it might circumvent certain tools).<br> <annevk> ccameron: because of that a no-HDR default is reasonable.<br> <annevk> weinig: I think any kind of sandboxing flag that we do should be absolute.<br> <annevk> ccameron: this would break YouTube embeds.<br> <annevk> weinig: that seems really easy to work around. It could be a quirk for a while that we work on phasing out.<br> <annevk> weinig: there's just not enough video websites for this to be a real problem.<br> <annevk> weinig: I'm also not sure it's such a big concern to break it as it's still early HDR days<br> <smfr> q+<br> <annevk> ccameron: I'm trying to give no-limit a go, gathering feedback as I go, but am prepared to switch to SDR. But for now we have quite a few partners that expect no-limit...<br> <astearns> ack smfr<br> <annevk> smfr: 1) I'm doubtful about great resets. Much less concerned about starting with less HDR and going towards more. 2) Who are the people that really want great HDR?<br> <annevk> ccameron: for 2) name any website that does a gallery of photos and they have opted in.<br> <annevk> smfr: Do they care about HDR in CSS images, SVG images, etc? Or primary content only?<br> <annevk> ccameron: mainly the primary content, but I've had people complain about it not being present in the gallery view (server-side downscaled images, say 6 in a row)<br> <annevk> ccameron: next steps?<br> <annevk> smfr: We have to check internally on some things.<br> <annevk> annevk: Do these websites rely on no-limit or specify the CSS property?<br> <smfr> q+<br> <annevk> ccameron: They rely on no-limit. Some enforce lower limits server-side.<br> <astearns> ack smfr<br> <annevk> smfr: Would it be possible for Google-controlled ad networks to control the amount of HDR?<br> <annevk> ccameron: I can ask, not sure I can answer.<br> <annevk> astearns: Okay, so smfr is going to be checking if the default for video could be constrained. ccameron is going to check on ad networks (but might not be able to answer).<br> <annevk> astearns: I'm against not specifying a default.<br> <annevk> astearns: If we specify constrained and Safari ships that, we can maybe change it. But if we go with no-limit we can't change it.<br> <annevk> ccameron: Keep in mind, it'd be pretty hard for us to change it at this point.<br> <annevk> ccameron: It seems unlikely that if the standard ends up on something other than no-limit, Chrome would be able to align...<br> <annevk> weinig: I don't agree with the idea that HDR will make things worse. It's really easy to make shitty web content without HDR. I don't think this will make it significantly worse.<br> <annevk> ccameron: I also think there's a possibility that enshrining SDR will make the web look shittier as people end up expecting their images to look bad.<br> <annevk> smfr: I think HDR can be a real problem for people.<br> <annevk> weinig: I think we can impose limits, but I don't think any of it will deter people from writing bad HDR.<br> <annevk> ccameron: I think a limit on cross-origin documents seems far more reasonable and might be doable.<br> <annevk> smfr: Question about iframe elements. If you apply the property on the element, does it impact the nested document?<br> <annevk> weinig: CSS logic says no.<br> <annevk> smfr: Fair, I just want it to be clear as it might go against expectations.<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-2755603107 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 26 March 2025 19:53:11 UTC