Meeting minutes
github: w3c/
w3c/csswg-drafts#11788
github: w3c/
ccameron: this is to avoid a divide by zero
<ccameron> the epsilon should only be used to color match (very exactly) with an image
<ccameron> this feature is good enough without eps
<ccameron> it's purely numerical
<ccameron> can set to like 0.5 even
<ccameron> the epsilon value is in the gain application color space (which is linear, and is either "base image" primaries or "alternate image" primaries)
<ccameron> in practice, that's sRGB, P3 or Rec2020 primaries
<ccameron> what's the gain application color space?
<ccameron> primaries of the first space specified is most "normal" default
github: w3c/
RESOLUTION: require strict inequality for H1 and H2
github: w3c/
Most edits done, need to discuss about allowing a single value or not
WPT allows single value
RESOLUTION: allow single value, well defined
<ccameron> w3c/
w3c/csswg-drafts#11558
github: w3c/
<jyasskin> ccameron: We probably won't agree on the default value. Having auto be browser-chosen and map to a single value .. maybe it's start on one state, and we'll eventually agree on something and be able to standardize that.
<jyasskin> ccameron: But I think I can't change several years of Chrome behavior, and good HDR doesn't need reduction, and the concern that HDR content will get mastered poorly if constrained by default.
<jyasskin> ccameron: I think we should have auto do what the browser wants, and provide the signal that the user left the default instead of explicitly asking for one of the options. Is that reasonable?
<jyasskin> simon: Apple doesn't hav etoo much information. We want auto to be uniform for all elements. Ideally we don't want images+videos to have different behavior if 'auto' is applied to both, but we have historical behavior we might have to support.
<jyasskin> simon: Can't commit that auto will be the same for all elements. Don't want heuristics ... might decide full-screen will allow full HDR.
<jyasskin> simon: Don't plan any in-page heuristics like "image is next to text".
<jyasskin> simon: Question about HDR-css colors vs HDR images & video: are we agreed that the dynamic-range-limit property affects both box decorations and content?
<jyasskin> <yes>
<jyasskin> ChrisL: We don't have syntax, and we're waiting for someone to do it, but we intend it to affect everything. If you want a particular thing, you should select it.
<jyasskin> simon: We do have a bug, but that's a bug. When people start specifying these colors, people might want to specify colors and replaced content separately.
<jyasskin> ccameron: Can specify different colors for different elements.
<jyasskin> simon: Videos have internal controls (??) which might want different color limits.
<jyasskin> ChrisL: I'm writing some tests.
<jyasskin> ChrisL: WPT is SDR & sRGB-only, but you can still test color mapping. Don't know how you'll get a headroom value.
<jyasskin> ChrisL: Does Apple have concerns?
<jyasskin> simon: Haven't digested the spec enough. Any concerns would be in terms of how HDR colors coexist with other content. To prevent annoying use.
<ccameron> proposed resolution: add "auto" value, which maps to browser-defined value (1 of the 3)
<jyasskin> ccameron: Suggest we sleep on this.
<jyasskin> simon: Think I'm ok resolving to add an 'auto' value, but not ready to say exactly how it behaves. Not ready to say it applies equally to images and video.
<jyasskin> github-bot: end topic