- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Jan 2025 21:23:13 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-color-6] How to support color math involving more than one color?`, and agreed to the following: * `RESOLVED: Yes to this issue, let's get it in a spec and start work on it` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> lea: a while back we resolved to adopt relative color syntax<br> <kbabbitt> ...<br> <kbabbitt> ... it's now in every browser, allows for math based on components of colors<br> <kbabbitt> ... use cases that involve more than one color keep cropping up<br> <hober> q+<br> <kbabbitt> ... e.g. mixing certain components from one color and other compionents from another<br> <kbabbitt> ... had an internal use case using components from one color and alpha from another<br> <kbabbitt> ... polyfilling other features can require components from multiple colors<br> <kbabbitt> ... e.g. two color operations like blending modes<br> <kbabbitt> ... it seems clear that there are use cases for this to be possible in some way<br> <kbabbitt> ... question is what's the best syntax<br> <kbabbitt> ... possibly extending color-mix but that could be a more complex syntax<br> <kbabbitt> ... not extensible to more than 2 colors<br> <kbabbitt> ... in another issue we resolved to add color-extract function<br> <kbabbitt> ... security and privacy implications so we might not see that anytime soon<br> <kbabbitt> ... it seems to me an extension on existing RCS is probably best way<br> <kbabbitt> ... but still how do we reference components of additional color?<br> <kbabbitt> ... could kick the ball down to authors and ask them<br> <kbabbitt> ... would prefer not to<br> <kbabbitt> ... if there's a user need we could do that later<br> <kbabbitt> ...ideally there should be default names like there are for first color<br> <kbabbitt> ... some might be comfortable with functional syntax eg. c(2)<br> <TabAtkins> q+<br> <kbabbitt> ... fantasai and I think there re too many parens already<br> <weinig> q+<br> <ChrisL> prefer c2 to c(2) or c-2<br> <kbabbitt> ... auto generating idents like c2 seems nicest way<br> <hober> q-<br> <kbabbitt> .... fine for initial vetsion to be limited in # of colors it supports<br> <emilio> q+<br> <kbabbitt> ... don't thinkm I've seen a quse case requiring more than 3<br> <kbabbitt> ... if impls want a pre defined max that's fine<br> <kbabbitt> ... other details like what if you're ref'ing an ident and you have fewer colors than that, proposals about that<br> <kbabbitt> ... can iron these out later if there's consensus on general direction<br> <astearns> ack TabAtkins<br> <kbabbitt> TabAtkins: agree with this and generally think lea's ideal case is right way to do it. +1<br> <astearns> ack weinig<br> <kbabbitt> weinig: one thing I couldn't quite understand: if you want to use channels from 2 different color spaces, would RCS support that?<br> <lea> qq+<br> <kbabbitt> ... usually RCS extracts channels in single color space<br> <kbabbitt> ... would we need to augment to define extraction?<br> <kizu> q+<br> <kbabbitt> lea: yes you can nest RCS, each time you convert to color space<br> <kbabbitt> weinig: so if you want lightness to multiply every rgb channel, extract lightness and thne put it in every channel?<br> <kbabbitt> lea: each op is done in one color space<br> <kbabbitt> ... base color can be a relative color<br> <kbabbitt> weinig: say you have a color you want its lightess from<br> <kbabbitt> ... and want to multiply every channel of an rgb color by that value<br> <kbabbitt> .... to brighten its intensity<br> <kbabbitt> lea: why not operate on lightness itself?<br> <kbabbitt> weinig: that's fair<br> <kbabbitt> lea: we can revisit color-extract later which would allow that<br> <kbabbitt> ... not sure there's enough cases but could revisit<br> <kbabbitt> weinig: your argument is strong<br> <ChrisL> In general, doing math on gamma-encoded rgb channel values is almost never useful<br> <kbabbitt> ... also: are there other areas of CSS where extracting parts of it and using those would be useful?<br> <kbabbitt> ... so that instead of color-extract we have a more generic form<br> <kbabbitt> ... to avoid color-mix to mix thing<br> <kbabbitt> ... if we were to go the extract route are there other potential use cases?<br> <kbabbitt> lea: good question, can't think of any offhand<br> <kbabbitt> weinig: don't see any downside to adding support for multiple colors<br> <kbabbitt> ... could do other things if we want<br> <astearns> ack lea<br> <Zakim> lea, you wanted to react to weinig<br> <astearns> ack emilio<br> <kbabbitt> emilio: my question was similar to weinig's<br> <kbabbitt> ...what color space is used if you have multiple<br> <kbabbitt> ...would you get components of each color in its own color space, and ... target?<br> <kbabbitt> lea: this is already defined for RCS<br> <kbabbitt> ... color converted to color space you're working in<br> <kbabbitt> emilio: color space doesn't depend on input, depends on function being used<br> <kbabbitt> lea: precisely<br> <kbabbitt> ... that's how RCS works already<br> <astearns> ack kizu<br> <kbabbitt> kizu: we need something like this<br> <kbabbitt> ...while we still want to have this in situ way of doing things<br> <kbabbitt> ... might also want color-extract<br> <kbabbitt> ... cases where it's difficult to do this in one function<br> <kbabbitt> lea: you can use CSS variables<br> <kbabbitt> kizu: can you assing custom prop with color component and then reuse?<br> <kbabbitt> lea: yes, doesn't resolve until used but could use custom prop for calculations<br> <kbabbitt> kizu: if you are not registering them you could do this<br> <kbabbitt> ... if we are a fan of color-extract for security reasons<br> <kbabbitt> ...one solution might be to do it only in custom functions that return a color<br> <lea> e.g. `--lighter: calc(l * 1.2); color: oklch(from var(--color) var(--lighter) c h);` works fine<br> <kbabbitt> s/are/aren't/<br> <kbabbitt> [crosstalk]<br> <weinig> q+<br> <astearns> ack weinig<br> <kbabbitt> weinig: what are the security/privacy concerns with extract color?<br> <kbabbitt> lea: right now you could paint certaing colors on a canvas and read them but...<br> <kbabbitt> weinig: could use gCS to read serialization<br> <kbabbitt> lea: this adds vector to CSS itself<br> <kbabbitt> ...instead of needing JS<br> <kbabbitt> ... minor point but could imagine people raising concerns<br> <kbabbitt> ... e.g. previous meeting accent-color had concerns<br> <lea> or even `--lighter: calc(l * 1.2) calc(c * 1.05); color: oklch(from var(--color) var(--lighter) h);`<br> <kbabbitt> weinig: they have to be resolved for gCS anyway<br> <kbabbitt> ... if we allow that, you can always find out channels yourself<br> <kbabbitt> lea: fair enough<br> <kbabbitt> ... fwiw even if we decide that extract-color is useful, in many cases it would be verbose, this is simpler<br> <kbabbitt> weinig: not objecting just wanted to know what security and privacy concerns were<br> <kbabbitt> astearns: shall we resolve on adding this to spec><br> <kbabbitt> weinig: I feel we need more debate on syntax for getting components<br> <kbabbitt> ... or maybe a little more thought on if this concept of indexing into an array is something we're creating here<br> <kbabbitt> ...probably not the last time CSS will need indexing into an array of objects<br> <kbabbitt> ... coming up with a syntax we're OK with in future is useful<br> <kbabbitt> astearns: could have this proposal in spec with an issue sayting we need to think about component extraction<br> <kbabbitt> weinig: ok<br> <kbabbitt> astearns: Proposed: Yes to this issue, let's get it in a spec and start work on it<br> <ChrisL> +1<br> <kbabbitt> RESOLVED: Yes to this issue, let's get it in a spec and start work on it<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11533#issuecomment-2625624517 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 30 January 2025 21:23:14 UTC