[CSSWG] Minutes Color HDR Breakout 2025-03-26 [css-color-hdr]

=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 please respond by starting a new thread
   with an appropriate subject line.
=========================================


CSS Color HDR Breakout
======================

Initial value of `dynamic-range-limit`
    (Issue #11429)
--------------------------------------

  - If the default is constrained originally it can be fixed later, but
      no-limit would need to stay in place. However, there are concerns
      about SDR being too strong a presence and holding back HDR growth.
  - There is more research needed to reach a decision. smfr will check
      if the default for video could be constrained and ccameron will
      check what's possible to share about limiting HDR on ad networks.

Add target HDR headroom to `CanvasRenderingContext2D`
    (WHATWG Issue #11165)
-----------------------------------------------------

  - The group reviewed the proposal, available here
https://github.com/w3c/csswg-drafts/issues/11307#issuecomment-2718858571

===== FULL MEETING MINUTES ======

Present:
  Christoper Cameron
  Simon Fraser
  Cameron McCormick
  Alan Stearns
  Anne van Kesteren
  Sam Weinig

Scribe: annevk

CSS Color HDR Breakout
======================

Initial value of `dynamic-range-limit`
--------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/11429

  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.
  smfr: We only want to give video content no-limit access by default,
        not video element border colors and such.
  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.
  weinig: I think this makes it hard-if-not-impossible for content
          producers to match colors.

  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.
  ccameron: In another collaboration we very much try to make images
            and videos to behave the same.
  ccameron: Does constrained-high work with CoreAnimation? I think I
            have to use a shader.
  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.
  weinig: There are not that many websites. Can we get the websites
          fixed?
  smfr: It's the embedding pages that would have to set the Permissions
        Policy.
  weinig: What's the goal of doing that?
  smfr: To prevent abuse essentially.
  weinig: I suspect ads will just abuse video.
  smfr: Seems harder to deploy.
  weinig/ccameron: People will do it if they want it.
  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.
  ccameron: Also, even with constrained there can be bad content.

  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.
  smfr: I'm sympathetic to the argument that "valid" HDR will get
        better. I'm worried about antagonistic HDR.
  ccameron: That's why I have thought about making standard the default
            and you'd have to opt-in.
  weinig: And then you'd require Permissions Policy for cross-origin
          documents too.
  ccameron: antagonistic HDR already exists, I've been assigned bugs.
  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).
  ccameron: because of that a no-HDR default is reasonable.

  weinig: I think any kind of sandboxing flag that we do should be
          absolute.
  ccameron: this would break YouTube embeds.
  weinig: that seems really easy to work around. It could be a quirk
          for a while that we work on phasing out.
  weinig: there's just not enough video websites for this to be a real
          problem.
  weinig: I'm also not sure it's such a big concern to break it as it's
          still early HDR days
  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...

  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?
  ccameron: for 2) name any website that does a gallery of photos and
            they have opted in.
  smfr: Do they care about HDR in CSS images, SVG images, etc? Or
        primary content only?
  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)
  ccameron: next steps?
  smfr: We have to check internally on some things.

  annevk: Do these websites rely on no-limit or specify the CSS
          property?
  ccameron: They rely on no-limit. Some enforce lower limits
            server-side.

  smfr: Would it be possible for Google-controlled ad networks to
        control the amount of HDR?
  ccameron: I can ask, not sure I can answer.

  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).
  astearns: I'm against not specifying a default.
  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.
  ccameron: Keep in mind, it'd be pretty hard for us to change it at
            this point.
  ccameron: It seems unlikely that if the standard ends up on something
            other than no-limit, Chrome would be able to align...
  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.
  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.
  smfr: I think HDR can be a real problem for people.
  weinig: I think we can impose limits, but I don't think any of it
          will deter people from writing bad HDR.
  ccameron: I think a limit on cross-origin documents seems far more
            reasonable and might be doable.

  smfr: Question about iframe elements. If you apply the property on
        the element, does it impact the nested document?
  weinig: CSS logic says no.
  smfr: Fair, I just want it to be clear as it might go against
        expectations.

Add target HDR headroom to `CanvasRenderingContext2D`
-----------------------------------------------------
  github: https://github.com/whatwg/html/issues/11165

  <astearns> Sam’s proposal for definitions to spec against:
             https://github.com/w3c/csswg-drafts/issues/11307#issuecomment-2718858571
  [Review of the proposal.]
  weinig: So this controls the HDR headroom for input into the canvas?
  ccameron: Yup.

Received on Wednesday, 26 March 2025 23:51:00 UTC