Meeting minutes
<astearns> breakout will start at 1:30 local time (21 minutes)
<astearns> (or earlier if you like)
accentcolor in Forced Colors Mode
<TabAtkins> github: w3c/
alisonmaher: we resolved previosuly about accentcolor system color takes it value from the accent-color property
alisonmaher: in forced color mode, various color properties will used ???
proposal is : we dont take author specified from accent-color property for forced color
mode
RESOLUTION: we dont take author specified from accent-color property for forced color mode
florian: are we ignoring it only as far as the keyword are concerned (accent-color / accent-color-text) ?
florian: but the effect on things remain ?
ChrisL: yes
lea: is there any way to combine multiple options of forced color ?
TabAtkins: no forced color force stuff thats the point
florian: ok so in forced color, everything is using the system accent and the property is just use for its own computed value no effect whatsoever
Define rec2020 color space to use 2.4 gamma
<TabAtkins> github: w3c/
ccameron: historically lot of confusion of rec709 and 2020 should use as gamma
ccameron: lot more effort in the video world to say rec709 and 2020 when they are displayed referred use display gamma
ccameron: display referred tell you how you go from pixel value to output light
<TabAtkins> ccameron: in contrast with scene referred
ccameron: proposal is to get 2020 definition to 2.4 gamma
ccameron: apple has changed already to use 2.4 gamma AFAIK
ccameron: we could solve this long historic confusion by switching to 2.4
ccameron: we could also do it for 709
ChrisL: yes should be a separate discussion
ChrisL: BBC agrees its the right thing
ChrisL: concern is that it was added in 2016 and its very visible change
ChrisL: it changes color
ChrisL: trying to look on WebArchive for data about compat but we dont have this data
ChrisL: so people will need to update if there is any usage and also for WPT
florian: can we resolve in a way that its only if web compatible
lea: i would be surprised if its not web compat
lea: new color formats takes a very long time to be adopted by authors, e.g. even HSL which has existed for decades has surprisingly low numbers
ChrisL: lets do this
proposal: make the change to 2.4 gamma for rec2020 unless it's not web compat
ChrisL: it doesnt change rec 2100
RESOLUTION: make the change to 2.4 gamma for rec2020 unless it's not web compat
add display-p3-linear
<TabAtkins> github: w3c/
ChrisL: this fit nicely with hardware. in practice people use p3, but linear-p3 is calculated anyway
ccameron: this space is coming from the Canvas world
proposal: add display-p3-linear to the predefined color-spaces
lea: maybe we should have linear version of all RGB color-spaces already existing
ccameron: we could start with srgb, 2020
<lea> s/lea: maybe we should have linear version of all color-spaces already existing/lea: maybe we should have linear version of all RGB color-spaces already existing/
RESOLUTION: add display-p3-linear to the predefined color-spaces
Make channel values in relative color syntax optional
<TabAtkins> github: w3c/
ChrisL: the idea is lot of use case are deal by a new relative color syntax when you dont specifify the color space because you just want to change the alpha
<TabAtkins> alpha(<color> / <alpha>)
ChrisL: Im proposing a new relative syntax for just changing the alpha : alpha(<color> / <alpha>)
ChrisL: 2 syntaxes proposed : alpha or opacity
ChrisL: people prefers alpha
TabAtkins: I think its a good move
<ChrisL> proposal: add an alpha-only RCS function alpha()
lea: I though the thread was about making components optional in RCS
ChrisL: the good part of this new syntax is that you dont have to specifiy the color space which prevent mistakes
RESOLUTION: add an alpha-only RCS function alpha()
Colors where all channels (except) alpha have a value of none
<TabAtkins> github: w3c/
lea: this is very related
lea: to the previous resolution
lea: we already have a resolution to extend analogous components to a set of components
<lea> w3c/
lea: we used to have the concept of analogous component when you are converting LAB to LCH
L is analogous component in both, so we dont have to convert `none` to 0
lea: but if A and B both none, even if not individually analoguous, we now extend this for set
lea: so they both stay none
lea: what happen when you consider the empty set
<TabAtkins> lea: So if L in lch is analogous to L in lab, then ch (as a set) are analogous to ab (as a set) too
lea: when empty set, all components are analoguous together. so we don't need to convert any of them to 0 regardless of the colorspace
TabAtkins: yes we already resolved on that
ChrisL: what about transparent ?
ChrisL: we could add new keyword opaque for rgb(none none none 0%)
ChrisL: new current is opaque, different from already existing transparent
florian: until there is a demand for this keyword, maybe lets not do this
Proposal: close, no change
ChrisL: I agreed the keyword opaque could exist
<lea> PROPOSED RESOLUTION: No new `opaque` keyword until motivated by author demand / use cases
romain: this is not very different from transparent
romain: but transparent already acts as being all none
ChrisL: because we do everything in pre multipled, yes it acts the same
romain: when a framework defines its color as a color-mix with a variable you can influence, there is no way to have the other side color
TabAtkins: for this usecase why you wouldnt use the new alpha function ?
romain: because you influence not just the alpha with color-mix
romain: lets take it back to the issue to better describe it
no resolution, we will take it back to the issue
How to handle infinite values in color functions?
<TabAtkins> github: w3c/
TabAtkins: guillaume asked what do we do if you put infinity into one of the channels ?
TabAtkins: when you do conversion, it will generally produce NaN
TabAtkins: is it intended ?
lea: how do we handle hue being infinite ?
TabAtkins: I said that infinity is fine
TabAtkins: it's simply a very big value
TabAtkins: we should do the same for 1million or infinity
TabAtkins: romain find clamping infinity to large value give good result for conversion
ChrisL: it's wrong because any define number gives a actual result, infinity does not
TabAtkins: for hue infinity it's 0
TabAtkins: infinity shouldnt diverge from a very big number
TabAtkins: if you mix something with big number hue, you still get a valid hue
florian: its not define (different on browser/hardware) but it's still a value
florian: for big value, we dont define how you clamp. its UA defined
florian: in this specific case, we have coordinate space, and depending on how we clamp, it can make giant changes
TabAtkins: just dont use big numbers
ChrisL: we had another issue closed because you said it was fine on all colorspaces, while it was okay only on srgb
TabAtkins: that's the same behavior for infinity in many places in CSS like length
florian: the problem pre-exist in other places like width and height
<TabAtkins> `width: calc(infinity * 1px)` will give you an arbitrary very large length, might not have any meaning to the author
florian: even with infinity for both width and height you not sure having a square
florian: there is just no guarantee whatsoever
florian: dont expect something useful necessarily
TabAtkins: its also true for any arbitrary large value
TabAtkins: so are color so different that we need special behavior for infinity
<ChrisL> So basically `calc(Infinity)` is legal, and please don't do that
TabAtkins: or we just say author should not use infinity, whatever happen is undefined
TabAtkins: the remaining question is when we do color conversion, do we want to specify in the spec that infinity and large value should be clamp to a specific large value
ChrisL: I prefer not have that in the color spec, but in values & units
TabAtkins: The spec says that if there are implementation limit, you should clamp infinity/large to this limit
TabAtkins: we should make it clear that there is an implementation limit
proposal: clarify that color channels have an UA define limit for values, which affect infinity clamping
TabAtkins: you should get the same behavior for infinity and arbitrary large value
RESOLUTION: clarify that color channels have an UA define limit for values, which affect infinity clamping
Declared value serializations of absolute and relative colors
<TabAtkins> github: w3c/
ChrisL: historically we started by the declared and computed is what you serialize
ChrisL: its actually not true for named color, currentcolor, transparent
ChrisL: Sam W points out that we lose stuff like calc()
<ChrisL> "Should the declared value serialization of all RCS colors maintain follow the first paragraph of section 11.2, or does the first paragraph only apply to RCS colors that have currentcolor origin colors?"
<TabAtkins> w3c/
TabAtkins: especially for RCS how much information do we preserve ?
TabAtkins: for old color syntax, we are stuck anyway
TabAtkins: for new syntax, lets not carry this behavior : we should compute like other properties so calc() tree are preserved for serialization
<TabAtkins> TabAtkins: I bleieve this is Sam's request, too
matthieud: so currentcolor should serialize currentcolor for modern syntax
proposal: for all new color syntax introduced since color 4 ; serialization of calc() tree should serialize normally (as computed value)
RESOLUTION: for all new color syntax introduced since color 4 ; serialization of calc() tree should serialize normally (as computed value)
Computed value and serialization of Infinity and NaN in color functions
<TabAtkins> github: w3c/
TabAtkins: because we have to resolve things and don't resolve calc(), naked infinity is invalid, have to wrap in calc()
TabAtkins: no longer necessary, and at used value time you get a large value that we clamp to
<romain> +1
TabAtkins: objections to close as invalid (now)?
matthieud: so infinity resolves as infinity?
TabAtkins: computed would be calc(infinity), and used value is the clamped used value
RESOLUTION: Close issue as (now) invalid
<TabAtkins> github: w3c/
Define that color interpolation uses color-mix() if necessary
<TabAtkins> github: w3c/
TabAtkins: Values 4 says that colors are interpolated in sRGB. Colors 5 defined actual interpolation
TabAtkins: but neither says what to do if currentColor is involved, b/c it can only be resolved at computed value time
TabAtkins: for any cases that can't be resolved, we should use color-mix() to serialize
lea: makes sense
ChrisL: yes
TabAtkins: +1 from Kevin also
TabAtkins: How does it work for AccentColor?
ChrisL: system colors resolve to sRGB values and then you can mix them
<TabAtkins> fantasai: ideally all the system colors would be like currentcolor, but i htink we resolved it's too much work
<TabAtkins> lea: why is that ideal?
<TabAtkins> fantasai: some practical reasons, dunno
TabAtkins: also some compat issues e.g. around CanvasText and Canvas for initial colors
<TabAtkins> lea: but if you change color-scheme, the system colors shoudl change, yeah?
<TabAtkins> fantasai: Right, that's not how they work today.
fantasai: if you inherit a system color into an element with a different color-scheme, it won't change in response
fantasai: even though maybe you'd want it to
RESOLUTION: Use color-mix() to serialize any interpolation that can't be resolved at computed-value time
(currently just currentColor mixes)
auto value of dynamic-range-limit
<TabAtkins> github: w3c/
ccameron: Main question is what does this do
ccameron: one def works for me, other definition I'm allergic to
ccameron: Model we're converging to is, you get a value of headroom from display, then you plug that into tone-mappings, and that gets you a deterministic result
ccameron: all elements are impacted by this value the same way
ccameron: you can do limits on top of that
ccameron: what does 'auto' do?
ccameron: if auto maps to some hdr headroom value uniformly, so that two different videos get rendered with the same headroom, that's fine
ccameron: but if they get rendered with different headroom depending on [whatever], that's bad
ccameron: comment from April 2nd is basically this, is the auto here about using heuristics, or is browser using default value?
ccameron: Doesn't need to even need to map to one of the standard values
ccameron: but just be consistent across elements
ccameron: want it to be predictable behavior
ccameron: you could have a browser that examines content and decides headroom per page, but element-per-element is bad
ccameron: if this matches what WebKit might want to do, then fine to tighten up language around that
<TabAtkins> fantasai: can't rmemeber where we landed on
<TabAtkins> fantasai: dont' think doing an element-by-element smapling makes sense
<TabAtkins> fantasai: you're right, two videos shoudl use the same
<TabAtkins> fantasai: i think the idea was less about customizing per element, and maybe about which html elements get different bheavior? or media types? something.
<TabAtkins> ChrisL: some discussions assumed video is always HDR and images are always not, but we changed that
<TabAtkins> fantasai: right, so i think some of the tweaking was from that perspective
<TabAtkins> fantasai: the other thing someone mentioned somewhere was, if something is fullscreen we give it full headroom; otherwise it's constrained
<TabAtkins> ccameron: i think that's compatible with what i'm dsicussing
<TabAtkins> ccameron: auto could map to constrained, but if there's a fullscreen the whole page gets more headroom
<TabAtkins> fantasai: so the whole fullscreen element gets more headroom, and the rest of the page does too (but probably not visible)
<TabAtkins> fantasai: i think tho that the apple people here at this hour don't have the context for
<TabAtkins> fantasai: but i think we could agree there shoudlnt' be a content-based heuristic per-element. everything should be whole-page
<TabAtkins> matthieud: so take back to the issue to make sure we have feedback from the right people
fantasai: but we should get input from the people who know what they're talking about
<TabAtkins> ccameron: you also disucssed a limited boost to HDR #10296, some people author their hdr badly
<TabAtkins> ccameron: common in HLG videos shot by phones, it just effectively makes your sccreen brighter without actually using the range. it's a tragedy, we're digging our way out of it.
<TabAtkins> TabAtkins: it doesn't sound like we can actually hit a resolution on anything yet. we'll take it back to the issue.
<TabAtkins> ChrisL: Sad that this is the fifth time we've gone back to the issue
<TabAtkins> fantasai: true, but we have advanced the discussion in this area since then, so unclear how this issue has morphed
<TabAtkins> ccameron: another future comment, hopefully at tpac - i have a spreadsheet of all hdr features, might be a good idea there to figure out where it fits in
Should color-mix() default to oklab interpolation?
<ccameron> https://
<TabAtkins> w3c/
<TabAtkins> github: w3c/
lea: In past, we resolved that gradients should interpolate in OKLab (but then reverted it)
lea: gradients don't require interpolation space by default
lea: arugment about what to do by default
lea: but a lot of web-compat baggage for gradients
lea: for color-mix() we decided to not have a default, and everyone needs to type interpolation space
lea: but vast majority of authors have no idea
lea: many say in srgbl because their colors are srgb
lea: or use something just because it's what they know
lea: srgb produces the worst result!
lea: there are arguments for a variety of default space
lea: but in any case, we should pick one
lea: because we're better placed than most authors to pick a space
lea: most authors don't have the background
lea: and it also adds a lot of noise, especially when nested
lea: noise:benefit ratio is way too high
lea: MDN page didn't even explain why you need this argument until we fixed it
lea: so... thats the situation
lea: so let's pick a default. I recommend OKLab because perceptually uniform, so percentages make sense
TabAtkins: I agree personally
TabAtkins: I think using rectangular space is the right choice
TabAtkins: so sounds reasonable to me
TabAtkins: proposed resolution, make color space optional in color mix
TabAtkins: and default to OKLab
PROPOSED: Make the color interpolation space of color-mix() to OKLab
ChrisL: There's compat issues wrt transitions and animations
lea: this is just a syntax question
ChrisL: There's compat issues wrt transitions and animations
<lea> 🎉
RESOLUTION: Make the default interpolation space of color-mix() to OKLab
<ChrisL> 0/
ChrisL: Should transitions and animations also default to OKLab? That would be a change.
TabAtkins: We don't currently have a property to control the transition/animation color space
TabAtkins: I know we've attempted to have color-interpolation-method property in SVG, but never went anywhere
TabAtkins: can't remember why
lea: Might want different spaces depending on the operation, e.g. compositing
TabAtkins: right, ccameron wanted linear for compositing
TabAtkins: could we put into transition-behavior?
lea: This is much bigger scope, but, we do keep running into cases where you want to set parameters about how other properties work
lea: control multiple things, either differently per property, or for all images, or
lea: doesn't make sense to add a property for each property to control, and also doesn't make sense to control only all at once
lea: wonder if set metadata about how properties or values behave
lea: don't have a concrete proposal, just thought of this idea
TabAtkins: Given we don't have syntax at hand...
TabAtkins: Being able to set certain defaults for particular contexts, e.g. URL parameter stuff for all URLs at once, potentially interesting
TabAtkins: so there's scope for defaults for different types of things.
TabAtkins: but that would be a different issue!
TabAtkins: anything else?
<Zakim> ChrisL, you wanted to ask about transitions and animations (which do have a legacy)
<TabAtkins> fantasai: we discussed color-interpolation, said no because different use-cases want different things
<TabAtkins> fantasai: but color-interp doesn't need to have a single value
<TabAtkins> fantasai: could be auto by default, could be shorthand for color-interpolation-gradient/etc
<TabAtkins> fantasai: that would give you the ability to have defaults and tweak them across the page, easy to reset
<TabAtkins> fantasai: change animation/gradients/transitions but not change compositing
<TabAtkins> fantasai: but yes, i think it's super verbose to have to say the color space in every function, but we do it a lot
<TabAtkins> fantasai: i'm realistically not gonna fuss with gradients every time
<TabAtkins> ChrisL: tho designers do
<TabAtkins> ChrisL: we know that not because they set the color space, but because they add 500 stops until it looks right
<TabAtkins> fantasai: so i think we shoudl pursue a set of color-interpolation-* properties
<TabAtkins> florian: suspect i agree. one thing that concerns me is - do we know how many longhands are part of this? can't grow the set forever
<TabAtkins> florian: do we have a good handle on how many things are reset by this?
<TabAtkins> fantasai: say you set c-i:transitions foo, gradient bar, else baz ...`
<TabAtkins> fantasai: but say we forgot about compositing
<TabAtkins> fantasai: your shorthand will take a single keyword, and will apply it to everything unless it should be different
<TabAtkins> fantasai: so compositing wouldn't get set by the longhand, just reset to initial
TabAtkins: because they all have a current behavior, so resetting to their initial value would be a no-op
TabAtkins: if we realize something later on that something new needs to be settable by the shorthand, and currently isn't
TabAtkins: e.g. if we add a new thing
TabAtkins: that seems less likely, because we can go through the things we need it for today
Florian: so addition isn't a problem, we just need to be careful when adding new things to say whether they get set or reset by the shorthand
End
ACTION: lea to draft color-interpolation property