11:08:52 <RRSAgent> RRSAgent has joined #css-color
11:08:56 <RRSAgent> logging to https://www.w3.org/2025/08/19-css-color-irc
11:08:57 <Zakim> RRSAgent, make logs Public
11:08:58 <Zakim> please title this meeting ("meeting: ..."), astearns
11:08:58 <romain> present+
11:09:22 <astearns> breakout will start at 1:30 local time (21 minutes)
11:11:39 <astearns> (or earlier if you like)
11:12:00 <TabAtkins> TabAtkins has joined #css-color
11:12:04 <ccameron> ccameron has joined #css-color
11:12:06 <ChrisL> ChrisL has joined #css-color
11:12:13 <ChrisL> present+
11:12:47 <matthieud> matthieud has joined #css-color
11:12:55 <alisonmaher> alisonmaher has joined #css-color
11:12:58 <alisonmaher> present+
11:13:08 <oriol> oriol has joined #css-color
11:13:25 <florian> florian has joined #css-color
11:13:29 <TabAtkins> ScribeNick: matthieud
11:14:16 <emilio> emilio has joined #css-color
11:14:20 <emilio> present+
11:14:34 <TabAtkins> Topic: accentcolor in Forced Colors Mode
11:14:37 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/11332
11:15:30 <matthieud> alisonmaher:  we resolved previosuly about accentcolor system color takes it value from the accent-color property
11:15:54 <matthieud> alisonmaher:  in forced color mode, various color properties will used ???
11:16:10 <matthieud> proposal is : we dont take author specified from accent-color property for forced color
11:16:26 <matthieud> mode
11:17:16 <matthieud> RESOLVED:  we dont take author specified from accent-color property for forced color mode
11:17:48 <matthieud> florian: are we ignoring it only as far as the keyword are concerned (accent-color / accent-color-text) ?
11:18:12 <matthieud> florian: but the effect on things remain ?
11:18:17 <matthieud> ChrisL:  yes
11:18:18 <lea> lea has joined #css-color
11:18:24 <lea> present+
11:18:46 <oriol> present+
11:19:15 <matthieud> lea: is there any way to combine multiple options of forced color ?
11:19:26 <matthieud> TabAtkins: no forced color force stuff thats the point
11:20:46 <matthieud> 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
11:20:51 <TabAtkins> Topic: Define rec2020 color space to use 2.4 gamma
11:21:02 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/12574
11:21:27 <matthieud> ccameron:  historically lot of confusion of rec709 and 2020 should use as gamma
11:22:03 <matthieud> ccameron: lot more effort in the video world to say rec709 and 2020 when they are displayed referred use display gamma
11:22:24 <matthieud> ccameron:  display referred tell you how you go from pixel value to ???
11:22:38 <TabAtkins> s/???/output light/
11:22:44 <TabAtkins> ccameron: in contrast with scene referred
11:22:50 <matthieud> ccameron:  proposal is to get 2020 definition to 2.4 gamma
11:23:00 <ChrisL> q+
11:23:16 <matthieud> ccameron: apple has changed already to use 2.4 gamma AFAIK
11:23:29 <matthieud> ccameron: we could solve this long historic confusion by switching to 2.4
11:24:08 <matthieud> ccameron:  we could also do it for 709
11:24:14 <matthieud> ChrisL: yes should be a separate discussion
11:24:25 <matthieud> ChrisL:  BBC agrees its the right thing
11:24:37 <matthieud> ChrisL: concern is that it was added in 2016 and its very visible change
11:24:42 <matthieud> ChrisL: it changes color
11:25:03 <matthieud> ChrisL: trying to look on WebArchive for data about compat but we dont have this data
11:25:13 <matthieud> ChrisL: so people will need to update if there is any usage and also for WPT
11:25:28 <matthieud> florian:  can we resolve in a way that its only if web compatible
11:25:39 <matthieud> lea:  i would be surprised if its not web compat
11:25:55 <matthieud> lea: new color format takes very long to be adopted by user like HSL
11:26:04 <matthieud> ChrisL: lets do this
11:26:32 <lea> s/lea: new color format takes very long to be adopted by user like HSL/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/
11:26:35 <matthieud> proposal: make the change to 2.4 gamma for rec2020 unless it's not web compat
11:27:07 <matthieud> ChrisL: it doesnt change rec 2100
11:27:51 <matthieud> RESOLVED: make the change to 2.4 gamma for rec2020 unless it's not web compat
11:27:58 <TabAtkins> Topic: add display-p3-linear
11:28:01 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/12596
11:29:22 <matthieud> ChrisL: this fit nicely with hardware. in practice people use p3, but linear-p3 is a bit better
11:29:53 <matthieud> ccameron: this space is coming from the Canvas world
11:30:13 <ChrisL> s/a bit better/calculated anyway/
11:30:20 <matthieud> proposal: add display-p3-linear to the predefined color-spaces
11:30:57 <matthieud> lea: maybe we should have linear version of all color-spaces already existing
11:31:22 <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
11:31:24 <matthieud> ccameron: we could start with srgb, 2020
11:31:32 <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/
11:32:38 <matthieud> RESOLVED: add display-p3-linear to the predefined color-spaces
11:32:53 <TabAtkins> Topic: Make channel values in relative color syntax optional
11:33:02 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/10689
11:33:26 <lea> q+
11:33:32 <matthieud> 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
11:33:33 <TabAtkins> alpha(<color> / <alpha>)
11:34:22 <matthieud> ChrisL:  Im proposing a new relative syntax for just changing the alpha :  alpha(<color> / <alpha>)
11:34:34 <matthieud> ChrisL: 2 syntaxes proposed : alpha or opacity
11:34:39 <matthieud> ChrisL: people prefers alpha
11:34:56 <matthieud> TabAtkins: I think its a good move
11:34:57 <ChrisL> proposal: add an alpha-only RCS function alpha()
11:35:10 <lea> q-
11:35:45 <matthieud> lea:  I though the thread was about making components optional in RCS
11:36:05 <matthieud> ChrisL: the good part of this new syntax is that you dont have to specifiy the color space which prevent mistakes
11:36:34 <matthieud> RESOLVED: add an alpha-only RCS function alpha()
11:36:35 <TabAtkins> Topic: Colors where all channels (except) alpha have a value of none
11:36:41 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/10203
11:36:47 <matthieud> lea: this is very related
11:36:57 <matthieud> lea: to the previous resolution
11:37:36 <matthieud> lea:  we already have a resolution to extend ???? to a set of components
11:37:51 <lea> https://github.com/w3c/csswg-drafts/issues/10210
11:38:19 <matthieud> lea:  we used to have the concept of analogous component when you are converting LAB to LCH
11:38:23 <ChrisL> s/????/analogous components/
11:38:38 <matthieud> L is analogous component in both, so we dont have to convert to 0
11:39:03 <ChrisL> s/convert/convert `none`
11:39:10 <matthieud> lea: but if A and B both none, even if not individually analoguous, we now extend this for set
11:39:26 <matthieud> lea: so they both stay none
11:39:34 <matthieud> lea: what happen when you consider the empty set
11:39:41 <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
11:39:42 <ChrisL> q+
11:40:04 <matthieud> 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
11:40:17 <matthieud> TabAtkins: yes we already resolved on that
11:40:38 <matthieud> ChrisL: what about transparent ?
11:40:52 <matthieud> ChrisL: we could add new keyword transparent for rgb(none none none 0%)
11:41:20 <romain> q+
11:41:36 <TabAtkins> s/new keyword transparent/new keyword opaque/
11:41:51 <matthieud> ChrisL: new current is opaque, different from already existing transparent
11:42:25 <matthieud> florian: until there is a demand for this keyword, maybe lets not do this
11:42:52 <matthieud> Proposal: close, no change
11:43:47 <matthieud> ChrisL: I agreed the keyword opaque could exist
11:43:57 <lea> PROPOSED RESOLUTION: No new `opaque` keyword until motivated by author demand / use cases
11:44:51 <matthieud> romain:  this is not very different from transparent
11:45:27 <matthieud> romain: but transparent already acts as being all none
11:45:59 <matthieud> ChrisL:  because we dont everything in pre multipled, yes it acts the same
11:46:07 <matthieud> s/dont/do
11:47:04 <matthieud> 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
11:47:45 <matthieud> TabAtkins: for this usecase why you wouldnt use the new alpha function ?
11:47:55 <matthieud> romain: because you influence not just the alpha with color-mix
11:48:43 <matthieud> romain: lets take it back to the issue to better describe it
11:49:10 <matthieud> no resolution, we will take it back to the issue
11:49:22 <TabAtkins> Topic: How to handle infinite values in color functions?
11:49:29 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/10507
11:50:14 <matthieud> TabAtkins:  guillaume asked what do we do if you put infinity into one of the channels ?
11:50:23 <matthieud> TabAtkins: when you do conversion, it will generally produce NaN
11:50:32 <matthieud> TabAtkins: is it intended ?
11:50:40 <matthieud> lea: how do we handle hue being infinite ?
11:50:54 <matthieud> TabAtkins:  I said that infinity is fine
11:51:03 <matthieud> TabAtkins:  it's simply a very big value
11:51:13 <matthieud> TabAtkins: we should do the same for 1million or infinity
11:51:50 <matthieud> TabAtkins:  romain find clamping infinity to large value give good result for conversion
11:52:13 <matthieud> ChrisL: it's wrong because any define number gives a actual result, infinity does not
11:52:21 <matthieud> TabAtkins: for hue infinity it's 0
11:53:12 <matthieud> TabAtkins: infinity shouldnt diverge from a very big number
11:53:30 <matthieud> TabAtkins: if you mix something with big number hue, you still get a valid hue
11:54:04 <matthieud> florian: its not define (different on browser/hardware) but it's still a value
11:54:23 <matthieud> florian: for big value, we dont define how you clamp. its UA defined
11:55:08 <matthieud> florian: in this specific case, we have coordinate space, and depending on how we clamp, it can make giant changes
11:55:14 <matthieud> TabAtkins: just dont use big numbers
11:55:51 <matthieud> ChrisL: we had another issue closed because you said it was fine on all colorspaces, while it was okay only on srgb
11:56:07 <matthieud> TabAtkins: that's the same behavior for infinity in many places in CSS like length
11:56:37 <matthieud> florian: the problem pre-exist in other places like width and height
11:56:39 <TabAtkins> `width: calc(infinity * 1px)` will give you an arbitrary very large length, might not have any meaning to the author
11:56:45 <matthieud> florian: even both infinity you not sure having a square
11:56:52 <matthieud> florian: there is just no guarantee whatsoever
11:56:59 <matthieud> florian: dont expect something useful necessarily
11:57:00 <fantasai> fantasai has joined #css-color
11:57:09 <matthieud> TabAtkins: its also true for any arbitrary large value
11:58:11 <matthieud> TabAtkins:  so are color so different that we need special behavior for infinity
11:58:16 <ChrisL> So basically `calc(Infinity)` is legal, and please don't do that
11:58:27 <florian> s/even both infinity/even with infinity for both width and height/
11:58:29 <matthieud> TabAtkins: or we just say author should not use infinity, whatever happen is undefined
11:59:24 <matthieud> 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
11:59:48 <matthieud> ChrisL: I prefer not have that in the color spec
12:00:39 <matthieud> TabAtkins: The spec says that if there are implementation limit, you should clamp infinity/large to this limit
12:01:05 <matthieud> TabAtkins: we should make it clear that there is an implementation limit
12:01:55 <matthieud> proposal: clarify that color channels have an UA define limit for values, which affect infinity clamping
12:02:38 <matthieud> TabAtkins: you should get the same behavior for infinity and arbitrary large value
12:03:13 <ChrisL> s/color spec/color spec, but in values & units
12:03:22 <matthieud> RESOLVED: clarify that color channels have an UA define limit for values, which affect infinity clamping
12:03:26 <TabAtkins> Topic: Declared value serializations of absolute and relative colors
12:03:59 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/10305
12:04:38 <matthieud> ChrisL:  historically we started by the declared and computed is what you serialize
12:04:48 <matthieud> ChrisL: its actually not true for named color, currentcolor, transparent
12:05:18 <matthieud> ChrisL: Sam W points out that we lose stuff like calc()
12:05:31 <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?"
12:05:40 <TabAtkins> https://github.com/w3c/csswg-drafts/issues/10305#issuecomment-2125440877
12:06:10 <matthieud> TabAtkins: especially for RCS how much information do we preserve ?
12:06:24 <matthieud> TabAtkins: for old color syntax, we are stuck anyway
12:07:01 <matthieud> TabAtkins: for new syntax, lets not carry this behavior : we should compute like other properties so calc() tree are preserved for serialization
12:07:16 <TabAtkins> TabAtkins: I bleieve this is Sam's request, too
12:09:25 <matthieud> matthieud: so currentcolor should serialize currentcolor for modern syntax
12:10:17 <matthieud> proposal: for all new color syntax introduced since color 4 ; serialization of calc() tree should serialize normally (as computed value)
12:10:55 <matthieud> RESOLVED: for all new color syntax introduced since color 4 ; serialization of calc() tree should serialize normally (as computed value)
12:11:09 <TabAtkins> Topic: Computed value and serialization of Infinity and NaN in color functions
12:11:09 <fantasai> scribe+
12:11:16 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/8629
12:12:34 <fantasai> TabAtkins: because we have to resolve things and don't resolve calc(), naked infinity is invalid, have to wrap in calc()
12:12:49 <fantasai> TabAtkins: no longer necessary, and at used value time you get a large value that we clamp to
12:12:55 <romain> +1
12:13:20 <fantasai> TabAtkins: objections to close as invalid (now)?
12:13:50 <fantasai> matthieud: so infinity resolves as infinity?
12:14:10 <fantasai> TabAtkins: computed would be calc(infinity), and used value is the clamped used value
12:14:29 <fantasai> RESOLVED: Close issue as (now) invalid
12:14:48 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/12292
12:14:59 <TabAtkins> Topic: Define that color interpolation uses color-mix() if necessary
12:15:03 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/12292
12:15:28 <fantasai> TabAtkins: Values 4 says that colors are interpolated in sRGB. Colors 5 defined actual interpolation
12:15:46 <fantasai> TabAtkins: but neither says what to do if currentColor is involved, b/c it can only be resolved at computed value time
12:15:59 <fantasai> TabAtkins: for any cases that can't be resolved, we should use color-mix() to serialize
12:16:02 <fantasai> lea: makes sense
12:16:05 <fantasai> ChrisL: yes
12:16:12 <fantasai> TabAtkins: +1 from Kevin also
12:16:35 <fantasai> TabAtkins: How does it work for AccentColor?
12:16:54 <fantasai> ChrisL: system colors resolve to sRGB values and then you can mix them
12:17:26 <TabAtkins> fantasai: ideally all the system colors would be like currentcolor, but i htink we resolved it's too much work
12:17:29 <TabAtkins> lea: why is that ideal?
12:17:34 <TabAtkins> fantasai: some practical reasons, dunno
12:18:01 <fantasai> TabAtkins: also some compat issues e.g. around CanvasText and Canvas for initial colors
12:18:36 <TabAtkins> lea: but if you change color-scheme, the system colors shoudl change, yeah?
12:18:45 <TabAtkins> fantasai: Right, that's not how they work today.
12:19:11 <fantasai> fantasai: if you inherit a system color into an element with a different color-scheme, it won't change in response
12:19:16 <fantasai> fantasai: even though maybe you'd want it to
12:19:56 <fantasai> RESOLVED: Use color-mix() to serialize any interpolation that can't be resolved at computed-value time
12:20:08 <fantasai> (currently just currentColor mixes)
12:20:47 <TabAtkins> Topic: auto value of dynamic-range-limit
12:20:53 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/11558
12:21:22 <fantasai> ccameron: Main question is what does this do
12:21:31 <fantasai> ccameron: one def works for me, other definition I'm allergic to
12:22:03 <fantasai> 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
12:22:11 <fantasai> ccameron: all elements are impacted by this value the same way
12:22:15 <fantasai> ccameron: you can do limits on top of that
12:22:19 <fantasai> ccameron: what does 'auto' do?
12:22:43 <fantasai> ccameron: if auto maps to some hdr headroom value uniformly, so that two different videos get rendered with the same headroom, that's fine
12:22:56 <fantasai> ccameron: but if they get rendered with different headroom depending on [whatever], that's bad
12:23:17 <fantasai> ccameron: comment from April 2nd is basically this, is the auto here about using heuristics, or is browser using default value?
12:23:27 <fantasai> ccameron: Doesn't need to even need to map to one of the standard values
12:23:32 <fantasai> ccameron: but just be consistent across elements
12:23:40 <fantasai> ccameron: want it to be predictable behavior
12:24:09 <fantasai> ccameron: you could have a browser that examines content and decides headroom per page, but element-per-element is bad
12:24:32 <fantasai> ccameron: if this matches what WebKit might want to do, then fine to tighten up language around that
12:24:50 <TabAtkins> fantasai: can't rmemeber where we landed on
12:24:57 <TabAtkins> fantasai: dont' think doing an element-by-element smapling makes sense
12:25:01 <TabAtkins> fantasai: you're right, two videos shoudl use the same
12:25:19 <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.
12:25:31 <TabAtkins> ChrisL: some discussions assumed video is always HDR and images are always not, but we changed that
12:25:40 <TabAtkins> fantasai: right, so i think some of the tweaking was from that perspective
12:25:59 <TabAtkins> fantasai: the other thing someone mentioned somewhere was, if something is fullscreen we give it full headroom; otherwise it's constrained
12:26:06 <TabAtkins> ccameron: i think that's compatible with what i'm dsicussing
12:26:24 <TabAtkins> ccameron: auto could map to constrained, but if there's a fullscreen the whole page gets more headroom
12:26:48 <TabAtkins> fantasai: so the whole fullscreen element gets more headroom, and the rest of the page does too (but probably not visible)
12:27:03 <TabAtkins> fantasai: i think tho that the apple people here at this hour don't have the context for
12:27:23 <TabAtkins> fantasai: but i think we agree there shoudlnt' be a content-based heuristic per-element. everything should be whole-page
12:27:32 <fantasai> s/agree/could agree/
12:27:34 <TabAtkins> matthieud: so take back to the issue to make sure we have feedback from the right people
12:27:43 <fantasai> fantasai: but we should get input from the people who know what they're talking about
12:28:15 <TabAtkins> ccameron: you also disucssed a limited boost to HDR #10296, some people author their hdr badly
12:28:40 <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.
12:30:29 <TabAtkins> TabAtkins: it doesn't sound like we can actually hit a resolution on anything yet. we'll take it back to the issue.
12:30:53 <TabAtkins> ChrisL: Sad that this is the fifth time we've gone back to the issue
12:31:01 <TabAtkins> fantasai: true, but we have advanced the discussion
12:31:55 <fantasai> s/discussion/discussion in this area since then, so unclear how this issue has morphed/
12:32:00 <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
12:32:46 <TabAtkins> Topic: Should color-mix() default to oklab interpolation?
12:32:48 <ccameron> https://docs.google.com/spreadsheets/d/1zq6vhz3w2aCp9sgCidpGncQxybaDyBBr9p3nVqASaUQ/edit?usp=sharing
12:33:05 <TabAtkins> https://github.com/w3c/csswg-drafts/issues/10484
12:33:13 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/10484
12:34:05 <TabAtkins> q?
12:34:08 <TabAtkins> ack ChrisL
12:34:11 <TabAtkins> ack romain
12:34:14 <fantasai> lea: In past, we resolved that gradients should interpolate in OKLab (but then reverted it)
12:34:15 <ChrisL> q+
12:34:20 <fantasai> lea: gradients don't require interpolation space by default
12:34:28 <fantasai> lea: arugment about what to do by default
12:34:35 <fantasai> lea: but a lot of web-compat baggage for gradients
12:34:46 <fantasai> lea: for color-mix() we decided to not have a default, and everyone needs to type interpolation space
12:34:58 <fantasai> lea: but vast majority of authors have no idea
12:35:09 <fantasai> lea: many say in srgbl because their colors are srgb
12:35:16 <fantasai> lea:  or use something just because it's what they know
12:35:21 <fantasai> lea: srgb produces the worst result!
12:35:27 <ChrisL> q- lea covered it
12:35:33 <fantasai> lea: there are arguments for a variety of default space
12:35:34 <ChrisL> q-
12:35:37 <fantasai> lea: but in any case, we should pick one
12:35:44 <fantasai> lea: because we're better placed than most authors to pick a space
12:35:50 <fantasai> lea: most authors don't have the background
12:35:59 <fantasai> lea: and it also adds a lot of noise, especially when nested
12:36:15 <fantasai> lea: noise:benefit ratio is way too high
12:36:30 <fantasai> lea: MDN page didn't even explain why you need this argument until we fixed it
12:36:34 <fantasai> lea: so... thats the situation
12:36:52 <fantasai> lea: so let's pick a default. I recommend OKLab because perceptually uniform, so percentages make sense
12:37:24 <fantasai> TabAtkins: I agree personally
12:37:31 <fantasai> TabAtkins: I think using rectangular space is the right choice
12:37:33 <ChrisL> q+ to ask about transitions and animations (which do have a legacy)
12:37:41 <fantasai> TabAtkins: so sounds reasonable to me
12:38:07 <fantasai> TabAtkins: proposed resolution, make color space optional in color mix
12:38:14 <fantasai> TabAtkins: and default to OKLab
12:38:36 <fantasai> PROPOSED: Make the color interpolation space of color-mix() to OKLab
12:38:54 <fantasai> ChrisL: There's compat issues wrt transitions and animations
12:39:08 <fantasai> lea: this is just a syntax question
12:39:20 <fantasai> ChrisL: There's compat issues wrt transitions and animations
12:39:26 <lea> 🎉
12:39:31 <fantasai> RESOLVED: Make the color interpolation space of color-mix() to OKLab
12:39:36 <ChrisL> \0/
12:39:56 <fantasai> s/the color/the default/
12:40:28 <fantasai> ChrisL: Should transitions and animations also default to OKLab? That would be a change.
12:41:11 <fantasai> TabAtkins: We don't currently have a property to control the transition/animation color space
12:41:30 <fantasai> TabAtkins: I know we've attempted to have color-interpolation-method property in SVG, but never went anywhere
12:41:33 <fantasai> TabAtkins: can't remember why
12:41:56 <fantasai> lea: Might want different spaces depending on the operation, e.g. compositing
12:42:06 <fantasai> TabAtkins: right, ccameron wanted linear for compositing
12:42:19 <fantasai> TabAtkins: could we put into transition-behavior?
12:42:38 <fantasai> lea: This is much bigger scope, but, we do keep running into cases where you want to set parameters about how other properties work
12:43:05 <fantasai> lea: control multiple things, either differently per property, or for all images, or
12:43:21 <fantasai> 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
12:43:33 <fantasai> lea: wonder if set metadata about how properties or values behave
12:43:40 <fantasai> lea: don't have a concrete proposal, just thought of this idea
12:43:49 <fantasai> TabAtkins: Given we don't have syntax at hand...
12:45:06 <fantasai> TabAtkins: Being able to set certain defaults for particular contexts, e.g. URL parameter stuff for all URLs at once, potentially interesting
12:45:15 <fantasai> TabAtkins: so there's scope for defaults for different types of things.
12:45:20 <fantasai> TabAtkins: but that would be a different issue!
12:45:25 <fantasai> TabAtkins: anything else?
12:45:37 <TabAtkins> ack ChrisL
12:45:37 <Zakim> ChrisL, you wanted to ask about transitions and animations (which do have a legacy)
12:45:51 <TabAtkins> fantasai: we discussed color-interpolation, said no because different use-cases want different things
12:45:59 <TabAtkins> fantasai: but color-interp doesn't need to have a single value
12:46:12 <TabAtkins> fantasai: could be auto by default, could be shorthand for color-interpolation-gradient/etc
12:46:36 <TabAtkins> fantasai: that would give you the ability to have defaults and tweak them across the page, easy to reset
12:46:50 <TabAtkins> fantasai: change animation/gradients/transitions but not change compositing
12:47:08 <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
12:47:17 <TabAtkins> fantasai: i'm realistically not gonna fuss with gradients every time
12:47:20 <TabAtkins> ChrisL: tho designers do
12:47:33 <TabAtkins> ChrisL: we know that not because they set the color space, but because they add 500 stops until it looks right
12:47:55 <florian> q?
12:48:03 <TabAtkins> fantasai: so i think we shoudl pursue a set of color-interpolation-* properties
12:48:23 <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
12:49:04 <TabAtkins> florian: do we have a good handle on how many things are reset by this?
12:49:24 <TabAtkins> fantasai: say you set c-i:transitions foo, gradient bar, else baz ...`
12:49:35 <TabAtkins> fantasai: but say we forgot about compositing
12:50:05 <TabAtkins> fantasai: your shorthand will take a single keyword, and will apply it to everything unless it should be different
12:50:22 <TabAtkins> fantasai: so compositing wouldn't get set by the longhand, just reset to initial
12:50:42 <fantasai> TabAtkins: because they all have a current behavior, so resetting to their initial value would be a no-op
12:51:03 <fantasai> TabAtkins: if we realize something later on that something new needs to be settable by the shorthand, and currently isn't
12:51:15 <fantasai> TabAtkins: e.g. if we add a new thing
12:51:30 <fantasai> TabAtkins: that seems less likely, because we can go through the things we need it for today
12:51:53 <fantasai> 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
12:52:19 <fantasai> Topic: End
12:52:45 <fantasai> ACTION: lea to draft color-interpolation property
13:21:16 <ChrisL> rrsagent, make logs public
13:21:27 <ChrisL> rrsagent, make minutes
13:21:29 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/19-css-color-minutes.html ChrisL
13:29:01 <TabAtkins> TabAtkins has left #css-color
14:00:13 <oriol> q+
14:08:45 <oriol> q-
14:41:53 <florian> florian has left #css-color
15:53:03 <astearns> Zakim, end meeting
15:53:03 <Zakim> As of this point the attendees have been romain, ChrisL, alisonmaher, emilio, lea, oriol
15:53:05 <Zakim> RRSAgent, please draft minutes
15:53:06 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/19-css-color-minutes.html Zakim
15:53:11 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
15:53:12 <Zakim> Zakim has left #css-color