- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 13 Feb 2025 19:05:15 -0500
- To: www-style@w3.org
=========================================
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 Breakout
------------------
- RESOLVED: Add current proposal as a note into the spec (Issue
#11616: CSS syntax for HDR colors parameterized by
headroom)
- RESOLVED: Change high to no-limit (Issue #11698: New values for
dynamic-range-limit property)
- weinig will create a PR to clarify the language called out in issue
#11672 (Clarification on the grammar / spec text for
`dynamic-range-limit-mix()`)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Feb/0003.html
Present:
Said Abou-Hallawa
Chris Cameron
Simon Fraser
Pierre-Anthony Lemieux
Chris Lilley
Cameron McCormack
Chris Needham
Alan Stearns
Nicole Sullivan
Josh Tumath
Samuel Weinig
Scribe: joshtumath
Color HDR
=========
CSS syntax for HDR colors parameterized by headroom
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11616
ccameron: Taking some ideas in ICC, and also color matching with gain
map images in ISO
ccameron: A good way to deal with HDR colors
ccameron: We're not going to expose headroom directly
ccameron: recomputing every time there are changes is painful
ccameron: want to say headroom for this and that, and interpolate
between the two in UA
ccameron: the UA and device can limit it
ccameron: wanted to present the idea. not the definitive way to do it
ccameron: good to wait until ICC stuff is in a good place
ccameron: but that's the idea. wanted to see if anyone has thoughts
ChrisL: I really like the idea
ChrisL: for SDR, everything relative to medium white
ChrisL: but HDR there is no single value to use but we can't expose
the headroom
ChrisL: in the original proposal, you can say what the headroom is
for two colors
ChrisL: but when would it not be 0?
ChrisL: it's only defined in between. what if headroom is 2 and 4 on
an SDR display?
ccameron: It needs to be defined down to 0
ccameron: I'm still working on proposal for what to do with different
headroom values
ccameron: maybe we should build that into the syntax
ccameron: for images, you can say-- Oh. There is a reason why not to
have 0
ccameron: suppose you had content that you don't want to become HDR
ccameron: is that the most useful thing, I don't know
ChrisL: We have to define what happens when headroom is 0
ChrisL: could make the headroom 0 the default value. removes verbosity
ChrisL: could have n values
ChrisL: I don't want to make this too complicated. I want it to be
good enough
ccameron: I like that idea. I also think that if we workshop this,
having an initial version with only two values, one
headroom 0 sounds good
ccameron: maybe we do want the whole p?? wise thing
ccameron: it adds complexity, but I'd be happy to leave that out
for v1
ccameron: make sure the common case is super simple
smfr: The color that you render, the commutation of that color takes
into account screen brightness?
ccameron: Yes
smfr: Need to treat it like accent color and not paint it into canvas?
ccameron: I think canvas right now, it's a snapshot at a fixed
headroom. not possible to realize values at rendering
ccameron: so I haven't written this up. but 2d canvas has a headroom
that's 0 SDR
ccameron: so maybe render canvas by 2, but you need to tell canvas
what the effective headroom is
smfr: So there's no way of using the color painted as a proxy for
screen brightness?
ccameron: There better not be!
ccameron: the goal is to make it so you can't exfiltrate that
ccameron: you have to re-render your entire page when the headroom
changes, so we're aligned on that
smfr: The screen brightness things are ramped
smfr: I really want to avoid re-rendering on brightness change
ChrisL: What is the alternative?
pal: Let the rendering change deal with the viewing environment
weinig: You can't write arbitrary PQ values
pal: As long as we allow that, that's fine right?
pal: you're just writing HDR values and let the renderer deal with it
pal: as long as that's possible, everything else is optional
convenience
ChrisL: Understand that will be possible but that's not topic
pal: I think it's important. apps that will want additional control,
may want this, but otherwise should be able to let renderer do
its thing
weinig: I was thinking about this. if getting to parity with what
images and video can do... if images have to recompute each
pixel value...
weinig: then this will have to, too
<ChrisL> Agree that this is CSS parity for images/video
weinig: it's as if you have lots of tiny images that you've loaded
that have metadata with 'between these ranges'
weinig: comfortable for implementation if it mirrors what images and
video can already do
weinig: so I think that should quell smfr's concerns
weinig: it's something that engines already have to deal with
weinig: we should discuss alternative of this proposal. new property
with CSS color values that should be treated as if they are
HDR values and the system can do whatever tone mapping it
wants
weinig: I think there are some formats with no color map. system
decides how to tone map that
ChrisL: Yes PNG and ???? has that
ChrisL: it's just the values
weinig: So I think benefit to having the gain map, matching something
that uses PQ values directly
ccameron: Yes absolutely. right now it's going on in ICC where you
say 'here's my headroom dependent ICC profile'
ccameron: here's the transformation to get to headroom 3 1 0
ccameron: my goal with that is that can be something you can attach
to canvas
ccameron: 'here's the tone mapping for different headrooms'
ccameron: and that packet, I'd like to have the same packet between
video, images, CSS, canvas
ccameron: so that's another option
ccameron: perhaps that's better than the suggestion I had
weinig: We just want to get the model of what's happening in the
system. something like: you can attach to px some metadata
about how to tone map
weinig: and the compositor does it
smfr: I think both. you map at paint time and re-render the whole
buffer. I'm not sure whether we redraw in the first case but I
think we do
ccameron: For us, if something is in a layer, we can delegate to
the OS
ccameron: otherwise we rewrite every pixel when headroom changes
ccameron: we throttle it
ccameron: interpolate it out or in
weinig: But for systems with display lists, etc, they don't have to
block paint
weinig: A concern is, if we're privacy minded, we don't leak this
info through perf characteristics
ccameron: On some platforms it's observable
ccameron: but the goal is to push as far down pipeline as possible
weinig: But if we parallel what images can do, simplifies model
astearns: Where are we at. can we resolve to adopt?
astearns: or the idea of a different packet to send around something
to explore?
ccameron: I want something written down and give ICC something public
to point at
ccameron: it's an idea worth getting out to marinate
ccameron: get an idea of concerns. but I like the packet idea.
ccameron: we should try to incorporate that
weinig: Agreed needs to marinate. let engines experiment to see what
is feasible
weinig: Makes a lot more sense to figure out how for images and video
it will start playing before we tackle this
ChrisL: Would like to see this in spec so people can see what we're
looking at
ChrisL: can't currently make a HDR color
ChrisL: rather people get to see something
ChrisL: am rep to ICC. I know they tend to hide things until they're
public.
ChrisL: these are things to look at, and we need experimentation
that's coordinated. get a stick in the ground to kick around
weinig: Maybe we could say in the spec that this is changing
ChrisL: Yes
ChrisL: an explicit 'DO NOT SHIP!!!'
astearns: We can point to the issue and put in a competing proposal
too
ccameron: Everyone same page about: on chrome, you specify the color
and you get something bright
ccameron: the goal is for that to not be the case. you opt into a
brighter color is the goal
ccameron: otherwise you get gamut mapped to SDR
PROPOSED RESOLUTION: put current proposal in spec with a note that we
need to solve this and where discussion is happening
RESOLVED: Add current proposal as a note into the spec
New values for dynamic-range-limit property
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11698
said: The current value for dynamic-range-limit is 'high'
said: we believe UA may want more control based on system conditions
said: we propose value of auto to pick properties from system
astearns: There was an issue on auto. I thought you wanted to discuss
other values first
said: If we're talking about names, this property name is confusing
said: if we look at dynamic range, 0 is r.
said: dynamic range also is ????
said: high is full brightness, 0 is 0 brightness
said: I think we should change the names of values to show it's in
the negative side and limit the ??? of the video
said: is high high dynamic range or high limit on dynamic range
said: suggestion of 'none'
said: I think this is better than existing one
smfr: Or 'unconstrained'
ccameron: I wrote the names and with discussion I agree they only
make sense if you already know what they're doing
ccameron: I gave three options at F2F that emphasize these are the
limits the author is placing
ccameron: so how do you say that the page doesn't want to limit
itself?
ccameron: I agree 'high' is not intuitive
ccameron: so I am flexible on these terms
ccameron: I feel unable to give honest assessment. I was hoping we
could vote or something
ccameron: issues like auto value come from how these proposed values
are uncomfortable
astearns: I prefer no-limit
smfr: I like background: no-repeat!
ChrisL: I like no-limit as well
astearns: Should we resolve on that with option to bikeshed later?
ChrisL: Three values: you want SDR, as much HDR as you get and 'don't
go overboard'
nicole: Could it be 'default'?
smfr: Only one browser has shipped this
ccameron: Everyone serving HDR video will get a surprise if we change
the default behaviour
ccameron: not shipped yet
ChrisL: Just saying with no property specified, what do you get?
smfr: I think we decided at F2F it should be about limiting. Less HDR
than what the UA could give
smfr: but maybe you want in an image editor on the web to say full HDR
smfr: so the OS will constrain how much HDR allowed. and UA.
constraints may differ depending on in full screen
smfr: can you say 'go away constraint. I want HDR'
ChrisL: If you have one prop to limit it to less, and another to get
more, how do you explain that?
ChrisL: I'd rather one prop that gives you the full range. sounds
like an auto value to me
ChrisL: but I want to express give me it all or tone it down
ChrisL: and it should be on the same property
ccameron: The idea of saying I want all the HDR. Would you set that
on an element?
ccameron: you're saying 'hey wrap things up'
ccameron: one thing is when you think you're going in a certain
headroom at some point in the future, so you could set the
headroom early to get the effect
ccameron: or 'I know my page will use headroom 5'
ccameron: I view that as a hint to the OS of what to do. and asking
for permission
ccameron: the OS may want to revoke that
ccameron: my feeling about the ramping, it's not something-- if we
attach it to an element, it's not been great
smfr: That makes sense
smfr: it's like the wait lock API
smfr: so the property we're talking about is only a limiting property
weinig: smfr came to my conclusion
ChrisL: And I'm on the same page now as well
smfr: I think we can get back to bikeshedding
weinig: But auto vs high. I think the default of high or no-limit is
good
weinig: everything is inherently 'auto'
weinig: you say 'I don't need the system to do it'
weinig: that's a strong thing. you don't want to put in effort to
make sure images are non HDR
weinig: you're saying there may be HDR pixels in there but ignore them
weinig: existing concept of defaulting to 'do what you do' and then
let the user ramp it down
smfr: I think there are legacy reason why auto might make more sense
smfr: historically we've allowed video to be high, but we might not
want that for images
weinig: Do images not have high today?
smfr: We don't have HDR support in mobile safari
smfr: we want to avoid the HDR in the corner of your eye problem
weinig: You want to avoid accidental HDR? not annoying the user, the
user could put 'high' on themselves
weinig: I don't think having an annoyance as a blocker is going to be
effective. you could make an accidental prevention thing at
best
ccameron: I worry about the auto thing being a way to opt into a quirk
ccameron: I prefer no limit as a default and the UA performs
heuristics to make sure HDR is limited by default
ccameron: if a video occupies x % of pixel area, you let the image
shine through
ccameron: I think what limit is imposed by the UA needs to be imposed
on ????? together
ccameron: that I think will come back and hurt us
ccameron: I think best resolution is to say for now, do heuristics
for video, etc, and then the permission for headroom could
be something we let pages start doing
ccameron: I think the opt out option is introducing an inconsistency
to the model that will tear itself apart
ccameron: there is a continuum of pages that the author has specified
ccameron: so basically you specify that and the author says 'I'm
outside of that continuum'
ccameron: I think it will cause compatibility issues
ccameron: I think of it like: a heuristic about the UA is how I'd
like to accomplish that
smfr: ccameron said he would like the limits on the whole page, but
we can't do that because of the legacy video HDR issue
<ccameron> +1
pal: I think having the UA police obnoxious content is ??. It's up to
the author to make a page make sense
pal: if you don't want an obnoxious ad, don't let them on the page
pal: it's too late for the UA to deal with it
<ccameron> and to amplify pal's comment, if we auto-limit things too
much, then authors will get used to creating too-bright
content
weinig: One other option is to think about this from UA stylesheet
perspective.
weinig: is there a model where img elements get standard or whatever
as default. video gets high as default.
weinig: there are probably some version of this where concept is
still there but reasonable defaults for UA stylesheet
weinig: doesn't help people using HDR background image, though
weinig: someone could still accidentally have a HDR background image
said: I think you mentioned we should fall back to no limit
said: but I think opposite. no limit is like auto
said: some blind heuristics will not be able to do it the same way
astearns: All of this is intertwined. all the issues.
astearns: We need to make decisions on these three issues. I don't
think there's anything where we can say this is the output
of the meeting
ccameron: I agree we haven't resolved. I thought at the F2F we agreed
auto is not needed
ccameron: It sounds like that wasn't where we got to
ccameron: names is close to resolution. auto still remains no
consensus
astearns: Can we resolve to change high to no-limit?
PROPOSED RESOLUTION: change high to no-limit
RESOLVED: Change high to no-limit
astearns: I thought this conversation was useful. meet again in two
weeks?
<pal> Thanks for the super clear agenda
Clarification on the grammar / spec text for
`dynamic-range-limit-mix()`
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11672
weinig: So it's just a clarification. whether the mix() function
should take other mix() functions as the input?
weinig: and the other ?: could only 1 value in it make sense or
should min be 2
ccameron: Could have mix of mix. it seemed simpler to allow you to
mix one value with itself, and have fewer rules
weinig: It was more the grammar, maybe a typo. I can do a PR
ChrisL: Would be good
Received on Friday, 14 February 2025 00:05:48 UTC