- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 13 Mar 2025 19:20:22 -0400
- 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
---------
- There was not clarity on the goal of issue #11558 (auto value of
dynamic-range-limit) so discussion will return to the mailing
list.
- The debate on issue #11429 (Initial value of `dynamic-range-limit`)
focused on what was the best behavior for the web.
- One position was to not limit by default and make sure it's clear
when an HDR image is too bright as it will encourage authors to
make good content. The concern with that approach is that authors
may have a hard time figuring out how to fix their content.
- The other position was to have an opt-in so that the content was
presented well by default but authors with expertise will be able
to leverage the properties. The concern with that approach is
that it may not be the best once HDR is the prevalent content.
- Folks then discussed their goals for the property to leverage those
goals and reach consensus.
- There was a slight lean to have a sdr default with video override,
however a key voice wasn't on the call so discussion will return
to github.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Mar/0009.html
Present:
Said Abou-Hallawa
Christoper Cameron
Elika Etemad
Chris Lilley
Alan Stearns
Sam Weinig
Scribe: fantasai
Scribe's scribe: weinig
Color HDR
=========
auto value of dynamic-range-limit
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11558
astearns: 2 issues, about 'auto' value and about 'initial' value
ChrisL: Note that we changed 'high' to 'no-limit'
ccameron: With 'auto', I'm struggling to understand what the goal is
ccameron: Not necessarily agree with goal
ccameron: browser-defined incompatibility mode
ccameron: Might want to have UA limit how much headroom is available
ccameron: but that limit should be applied to page altogether
ccameron: don't want each element to get its own headroom
ccameron: ... if want to e.g. hint that you really want HDR, and once
can do constrained with video, etc. then can implement that
ccameron: so that's direction I would see it going
ccameron: Not a fan of 'auto' in current format for that reason
weinig: I'm also not clear on what 'auto' would do or why it would be
a good idea
weinig: seems like if property intention is to provide upper limits
on how much HDR headroom something should have, 'auto'
doesn't really make sense
weinig: Idk how authors would use that
astearns: Unfortunately Said who opened the issue isn't here
ChrisL: Agree that I don't think 'auto' adds much value.
ChrisL: incompatibility mode ... when you don't set anything
ChrisL: and then other values to get some sort of defined behavior
astearns: Table discussion until we have more clarity
Initial value of `dynamic-range-limit`
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11429
ccameron: Should it be auto or no-limit?
ccameron: I'm sympathetic to idea that if we're doing this ex-novo,
make HDR opt in and whatever for the default
ccameron: but given every browser is shipping HDR on video by default
ccameron: and HDR images is not implemented yet only due to technical
complexity
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
ccameron: or have mode where try to be smart in that property
ccameron: right now UA can do anything
ccameron: But I think everything should be limited on a page together
ccameron: if global limit, then adjust
ccameron: if there's behavior we want to care about
ccameron: better to let HDR images shine out, if too bright, that's
just bad content
ccameron: clear signal that your HDR content is not authored in a
good way
ccameron: we want people to integrate in a good way
ccameron: encourage people to create good content
ChrisL: I tend to agree with that
ChrisL: e.g. you could create lime green with flashing gif
ChrisL: we don't limit that
weinig: Piece we're missing is, what's the goal of this property?
weinig: establish goal, then we can figure out our values
weinig: but without that, it's hard for us to make smart decisions
weinig: general premise of protecting people from poorly designed
website is not our battle
weinig: But author may not know the source of images, so having
author's ability to limit
weinig: in this index, we're going to constrain HDR, because we don't
know what they contain
weinig: let's not waste that power
weinig: but default should be no limit, no use case for auto
fantasai: I believe that WebKit's position was that the initial value
should be constrained
fantasai: and things on a case by case basis should be marked
unconstrained by authors
fantasai: Unfortunately not sure of the details, smfr would know more
fantasai: authors do have the issue of things like 3rd party content,
ads,
fantasai: if the default is no-limit, those ads might do bad things,
and they would not know, because things works fine now
<fantasai> ads or user-generated content
ccameron: Would it be better to have a global hint?
ccameron: We have to deal with the fact that video is already not
constrained today
ccameron: lots of people count on that
fantasai: webkit/apple thinks a UA style sheet for video would help
ccameron: Some browsers are shipping HDR images already, would break
that behavior
ccameron: for chrome, this would break things for images and webgpu
canvas, which have already shipped
ccameron: hard to explain why we have this default a few years
from now
ccameron: why not have a global signal
ccameron: whole page, if you want to keep the old behaviors, you need
to opt into it
ccameron: roll that out slowly later
weinig: 2 weeks ago, position was that webkit/apple really wanted
images also to be HDR unconstrained
weinig: in addition to video
fantasai: I can't remember which elements were proposed to
except. ^_^;;
weinig: What if we split property in two, and have one limit apply to
things like video/image/canvas -- replaced content
weinig: and separate one that applies to CSS colors etc.
weinig: then you could decide... is background one or the other
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
Said: I tried to get high quality HDR, but still same experience
Said: So it makes sense to me, to always have mixed content always be
constrained
Said: and only allow no-limit for fullscreen(?)
Said: This is my experience with SDR and HDR in the same page
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)
ccameron: and they can also limit the range heuristically, based on
outlines
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
ccameron: dynamic-range-limit property is author saying what they want
ccameron: if UA wants to do something beyond that, is compatible
ccameron: Sympathetic to opt-in idea, but given where we are,
disagree.
astearns: With regards to separate properties idea, aside from images
and video, you can define a bg color as HDR color
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
ChrisL: You'd still get an HDR color, just a more subdued color
astearns: That's a fair argument for not having a constraint, since
we tend to avoid double opt in
weinig: We would re-imagine existing CSS colors as all being HDR
capable, as long as their components were large enough
weinig: it wouldn't be a double opt in, you just need a color bright
enough to warrant using some headroom
fantasai: The idea that the UA can do anything it wants
fantasai: works well in cases where the UA has the final say, like
background window
fantasai: but it doesn't work well when the author overriding things
fantasai: In that case, a property makes sense
fantasai: element by element makes sense
fantasai: but a different default for fullscreen or loaded alone
might make sense
fantasai: but allowing a page to have a mix of HDR and non-HDR might
make sense too
fantasai: Like YouTube, where there is video, but also other content
fantasai: but only the main video should be HDR
fantasai: magic limits later seems worse
fantasai: Should figure this out now, and make it work with the
cascade
fantasai: weird heuristics are worse, viewport metatag is awful
Said: We should take consideration the default, any possible auto
values, take into consideration the transition
Said: At this time [missed]
Said: For example eBay, suppose someone decided "well, now all
browsers support HDR, let's use this ability"
Said: [missed2]
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
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
weinig: We have to figure out and agree on our goal
weinig: sounds like we don't quite agree on it
weinig: Is the goal that videos, images are constrained or
unconstrained? constrained in some circumstances? browsers
can have different goals?
weinig: I see different goals here. We need to converge on the goal.
weinig: Another issue is that Chrome has shipped this, so we also
potentially have a compat problem here
weinig: Maybe Apple can give a concrete proposal
Said: My understanding is that we like to provide the nicest
experience for the user even during the transition period
Said: Having HDR without constraint doesn't seem nice
Said: so we want the default to be constrained-high for images
ccameron: One of my goals is to not lull people into the idea that
they have good content because it looks good by default
ccameron: I want to show exactly what was specified up to
capabilities of the machine
ccameron: and hope this will inform people to make good choices about
how they use HDR
ccameron: if specify too much, and end up getting 2x as bright
because ...
ccameron: There is concern that I'm authoring to 10, but not
knowing it
ccameron: HDR video authored with PQ is usually quite good.
ccameron: HDR images on iPhone, Pixel, etc are also good. They don't
blow your eyes out.
ccameron: But ?? video shot at iPhone and Pixel is way too bright,
looks bad, ruins people's eyes
ccameron: problem with that is, people were allowed to create the
content without seeing what they're specifying
ccameron: I think it's better to show what was specified, and hope
they are not making it unpleasant to view
ccameron: Should it turn out that we're wrong, and people can't do
this right even when seeing what they're producing, then
maybe ratchet down the defaults or global switch or
something
ccameron: If we limit things by default, they will create bad content
because won't see what they're specifying
ccameron: I want to give ecosystem a chance to get it right
ccameron: otherwise will be bad forever
Said: I disagree with ccameron
Said: Here's an example
Said: In WebKit, we limit animation to 60fps. But in Chrome, it uses
device frame rate
Said: Chrome has already hit a problem where the frame rate can be
200 or 500, some device has this kind of speed
Said: and Chrome can't cope with this speed, and begins to limit it
Said: So I think unlimited would give you a bad experience
Said: We want to give the normal user the best experience.
fantasai: Chris is making the argument we should give the author the
opportunity to get it right
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
fantasai: not just about the transition period
fantasai: constrained is a better default for the web
fantasai: sophisticated authors will get it right
fantasai: but many won't know how to make things right
fantasai: better to make things opt in
fantasai: You should not need to learn everything to use CSS
fantasai: shouldn't have to learn to turn down the headroom
astearns: Could be argued in either way
astearns: Could be hard to figure out how to make your photos look
right
fantasai: If you want extra brightness you're expecting but not
getting, then you can go looking for how to do it.
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
ccameron: I'm sympathetic to that argument, but in that case I would
suggest a default of SDR
ccameron: since constrained high is [missed3]
ccameron: I could go for that. And maybe there's a bridge to that
somehow.
ccameron: Keep going back to global thing.
ccameron: (something about gainmaps)
ccameron: even if you have a very small headroom
weinig: I do think that the ideal default would be SDR
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
weinig: majority of content that wants to benefit from HDR values
will learn about these properties
weinig: and in time get those properties set on them
weinig: whereas if we start with unconstrained or a middle ground, it
will always be fighting one battle or the other
weinig: Both argument fantasai made and astearns made, that each
group won't get behavior that makes sense
weinig: it would take video that's already HDR and make it not
weinig: but maybe that's OK
weinig: maybe there aren't enough websites that having this blip of
compatibility isn't doable
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
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
ccameron: but for video, don't have that
ccameron: in many cases no ability to even tell the OS to render
under constraints
ccameron: so that limits what we can do for video. Even if we want
to, in some OSes it is technically impossible
ccameron: I do horrible things to make it "work" in Chrome
ccameron: We're working on standards to improve the situation
ccameron: There's work going on in standards to improve video, to
have double-graded content
ccameron: but for right now.... it would be a big amount of work
ccameron: and it yes, there are pages that serve HDR content, usually
professional stuff and they are paying for the bandwidth
ccameron: I think there's a chance we could push in a different
direction in the future, but really built in right now
ccameron: Can we switch topic to names?
ChrisL: +1
astearns: I wonder if we can decide on an sdr default with video
override in the UA stylesheet
weinig: I think we really need Simon for that
weinig: Since I proposed that last time, and he had objected
astearns: OK, we'll take that back to the issue for now
New values for dynamic-range-limit property
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11698
<fantasai> Suggestions from ccameron at
https://github.com/w3c/csswg-drafts/issues/11698#issuecomment-2662695204
fantasai: It's not clear that constrained is less constrained than
standard
ccameron: Standard lines up with terminology and media query
ccameron: no-limit is pretty clear
ccameron: Do we agree on the two end points?
ChrisL: Yeah, it's just the middle one
ccameron: Constrained seems great to me, but I've been deep in this
for a long time
fantasai: Maybe we can resolve on standard and no-limit, and ask the
rest of the working group on names
ChrisL: we already are pretty resolved on standard and no-limit
fantasai: asking a person if constrained or standard is more
constrained...
<weinig> https://github.com/w3c/csswg-drafts/issues/11307#issuecomment-2718858571
Received on Thursday, 13 March 2025 23:20:56 UTC