[CSSWG] Minutes Color HDR Breakout 2025-02-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.
=========================================


Color HDR
---------

  - RESOLVED: Remove the sentence in spec that says if sum is zero,
              treat as invalid; possibly add new prose about splitting
              the percentage, and update tests (Issue #11678: How
              should checking for percentages summing to 0 work in
              dynamic-range-limit-mix() when calc() is used?)
  - RESOLVED: Modify spec text as discussed, to try and flesh out if
              there are blocking compositor issues in implementations;
              possibly add an appendix of test cases and blocking
              issues with platform limitations (Issue #11037: How
              should multiple layered elements with different
              `dynamic-range-limit` values behave?)
  - The group discussed issue #11704 (Add permission policy (or other
      mechanism) to irreversibly limit EDR) and what user and author
      expectations would be. There is a need to dive further into
      expectations and concerns that this needs to be addressed soon
      since HDR is starting to ship.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2025Feb/0016.html

Present:
  Said Abou-Hallawa
  James Craig
  Simon Fraser
  Pierre-Anthony Lemieux
  Chris Lilley
  Alan Stearns
  Samuel Weinig

Scribe: jcraig

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

How should checking for percentages summing to 0 work in
    dynamic-range-limit-mix() when calc() is used?
--------------------------------------------------------

  github: https://github.com/w3c/csswg-drafts/issues/11678

  weinig: Issue is that the spec for dynamic color mix has rules
          applied at parse time that check if value is zero
  weinig: if all percentages add up to zero, they are invalid, but
          calc() may not know if it's invalid yet
  weinig: Options: either define at calc time what do in that scenario,
          mark as invalid at computed style time, or have it behave as
          if all percentages are the same; evenly divided
  weinig: Someone brought up the a concern with 50 high 50 low example,
          nothing constrained, you'd get 33/33/33
  weinig: Currently we even split it, but worth considering when
          animating the ramps to zero
  ChrisL: People will ramp it for animation so we should ensure it's
          not jarring
  weinig: No current test for that.... but yes, should fix that
  weinig: Propose if all zero, treat as all at 33%
  ChrisL: Sounds reasonable

  PROPOSAL: remove the sentence in spec that says if sum is zero, treat
      as invalid; possibly add new prose about splitting the
      percentage, and update tests
  weining: I can take on an item to work up the correct prose for that
           change to splitting the percentage

  RESOLVED: remove the sentence in spec that says if sum is zero, treat
            as invalid; possibly add new prose about splitting the
            percentage, and update tests

How should multiple layered elements with different
    `dynamic-range-limit` values behave?
---------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/11307

  weinig: For multiple layered elements, need more added to clarifying
          the model underlying what this property actually does
  weinig: uses tone map compositing example to explain compositor
          controlling whether this is additional headroom
  ChrisL: We have a brief section on compositing... would be good to
          get better text
  weinig: Understanding what implementors would like to apply here
          would be useful
  weinig: and the constraints of existing compositors
  Said: The dynamic range limit is cascading, correct?
  weinig: Inherited but overridden by an explicit defining on higher
          specificity
  smfr: Yes, agreed at F2F that these are not multipliers
  ChrisL: Should be documented, possibly in an appendix...
  ChrisL: easy to write something that looks great from a color theory
          perspective but may not be implementable

  PROPOSAL: modify spec text as discussed, to try and flesh out if
      there are blocking compositor issues in implementations; possibly
      add an appendix of test cases and blocking issues with platform
      limitations
  weinig: WPT is lacking here because the color space can be modified
  ChrisL: and WPT is limited to sRGB

  RESOLVED: modify spec text as discussed, to try and flesh out if
            there are blocking compositor issues in implementations;
            possibly add an appendix of test cases and blocking issues
            with platform limitations

Add permission policy (or other mechanism) to irreversibly limit EDR
--------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/11704
  scribe: weinig

  smfr: Issues is ads in cross origin frames showing hdr
  smfr: one way to got is not allowing HDR cross origin
  smfr: or we could use the property
  smfr: or do we want to add to the iframe attribute that grants
        permissions
  smfr: Is the definition of the css property on an iframe even
        specified?
  smfr: does it apply to all the contents?

  astearns: Do we have any cases where things don't propagate down into
            an iframe?
  smfr: I think HDR is a little special, and we should we say something
  ChrisL: This is a about stopping ads doing bad things
  smfr: Yes, but it is also about explicitly letting some cross origin
        iframes
  smfr: this is partially a HTML issue, since the attribute would be
        in HTML

  astearns: The permission policy would be an attribute?
  smfr: Yes

  ChrisL: Is this being discussed in HTML?
  smfr: I don't think so

  pal: This is complex, but someone who made an HDR video would be
       upset if they got squashed when embedded
  smfr: Yeah, we currently always allow HDR on video
  smfr: so we may want to allow it to always work cross origin
  pal: Codepen is an extreme example, because it wants the iframe to be
       perfect
  pal: would be good to hear from website authors
  pal: the default of showing in HDR is better than not, but can be
       jarring
  astearns: Not sure who filed the issue, but the person who filed the
            issue seemed to want to be able to limit things
  smfr: Actually, it was filed by a webkit engineer
  smfr: but others have mentioned a concern of ads
  pal: Isn't the only thing you would ever want to do is make it all
       SDR?
  smfr: Not sure, might have HDR but not want flashy ads to be HDR
  pal: I think the website should probably have control
  smfr: I think both the website author and user
  smfr: defaults we choose are important
  astearns: And giving authors the tools
  smfr: no way to currently allow a hosting page to say it only wants
        SDR

  smfr: This is a sleeping problem, since we only just started shipping
        HDR now
  weinig: I am not sure the issue of an embedded YouTube not being HDR
          is that big a deal
  weinig: you can always put a tinted div over a video
  weinig: letting the hosting site make things SDR seems fine
  jcraig: We had a similar issue internally with a feature that dims
          things automatically when things are flashy, and there was a
          question of whether it was ok to change the artists intent
  jcraig: but ultimately, allowing the user to have the control was the
          way to go
  pal: Movies are mastered under the idea they will be the only thing
       displayed
  ChrisL: Yeah, but we can't do that on the web, we have to allow mixed
          content
  pal: Yeah, when a movie is watched on the web, it is already
       compromised
  pal: image gallery much more complicated
  astearns: ok, good talk, let's take this back to the issue

Received on Thursday, 27 February 2025 23:49:43 UTC