- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Jan 2025 22:12:48 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-color-5] Make interpolation method optional in `color-mix()`?``. <details><summary>The full IRC log of that discussion</summary> <kbabbitt> lea: a while back we resolved to have mandatory interpolation color space in color-mix()<br> <kbabbitt> ... because we worried ,what if a better color space comes along?<br> <kbabbitt> ... for interpolation<br> <kbabbitt> ... reality is that this has become noise in the fn<br> <ChrisL> q+<br> <kbabbitt> ... authors do not make informed decisions we expected<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <kbabbitt> ... they specify srgb not because they want to interpolate there but htat's the color space they're familiar with<br> <astearns> q+ ChrisL<br> <weinig> q+<br> <kbabbitt> ... or they think they have to because colors are srgb<br> <kbabbitt> ... we can make a more informed choice for this default<br> <kbabbitt> ... even if there's a better default later, this is better than what authors are currently doing<br> <kbabbitt> ... we also resolved lab should be default for gradients<br> <kbabbitt> ... we do have in gradients you don't have to specify interpolation space<br> <kbabbitt> ... so this would harmonize<br> <kbabbitt> ... I was in favor of not having a default, I think it would be a net gain to have a default now<br> <emilio> q+<br> <emilio> ack ChrisL<br> <astearns> ack ChrisL<br> <kbabbitt> weinig: I wanted us not to have a default<br> <astearns> ack weinig<br> <kbabbitt> ... I still think it's the right choice<br> <kbabbitt> ... in general I think the places where we've not been explicit about color spaces<br> <kbabbitt> ... have by and large been a mistake<br> <kbabbitt> ... and hard to claw back<br> <kbabbitt> ... if we live in a world where there are color spaces and people writing code for our platforms, they need to be aware of them<br> <lea> q+<br> <kbabbitt> ... I don't think hiding them has been an effective strategy<br> <ChrisL> qq+<br> <kbabbitt> ... in the engines, or the APIs we produce<br> <kbabbitt> ... people using srgb as default feels like educational problem which is solvable<br> <kbabbitt> ... not necessarily reason to force different default<br> <astearns> ack ChrisL<br> <Zakim> ChrisL, you wanted to react to weinig<br> <kbabbitt> ChrisL: you've exactly captured my viewpoint from 6 months ago<br> <kbabbitt> ... we give them that, they make good choices, they make terrible choices<br> <kbabbitt> weinig; I don't think people will make good choices to begin with, they make bad choices all the time<br> <kbabbitt> ... but I think in the expanse of time as more articles come out and more people come to understand what these concepts mean<br> <kbabbitt> ... that is a net positive<br> <kbabbitt> ... giving people the runway to learn these concepts is useful<br> <kbabbitt> ... slipping them under covers is useful in short term but not long term<br> <ChrisL> q?<br> <astearns> ack emilio<br> <kbabbitt> emilio: 2 questions<br> <kbabbitt> ... presumably if you mix with transparent the result is what you expect regardless of color space<br> <kbabbitt> ... or are there weird things there/<br> <florian> q+<br> <kbabbitt> ... I want to make this color semi transparent<br> <kbabbitt> weinig: if all you do is augment alpha that's same for all color spaces<br> <kbabbitt> emilio: right<br> <kbabbitt> ... does result color space depend on interpolation method?<br> <kbabbitt> weinig: there's not a concept of result color space<br> <kbabbitt> ... colors are colors and how you use them enforces color space<br> <kbabbitt> emilio: but you need to serialize ...<br> <kbabbitt> weinig: it serializes as what you mixed as i.e. output<br> <kbabbitt> ... in this proposal, output of color-mix will be by default oklab()<br> <kbabbitt> emilio: could be surprising<br> <kbabbitt> ... you omit color space, mix red + transparent and get some oklch value<br> <kbabbitt> ... have mixed feelings about this<br> <kbabbitt> ... if colors wouldn't be read so much from script I'd be happy to do this<br> <kbabbitt> ... maybe it's fine anyway<br> <kbabbitt> ... and people will ditch their old script<br> <kbabbitt> ... it's common to mix srgb colors, call gCS, and parse an rgba value<br> <kbabbitt> ... which would no longer work<br> <kbabbitt> weinig: it would already no longer work because modern syntax<br> <lea> q?<br> <kbabbitt> emilio: I think you get legacy syntax given legacy input<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to ask stupid question about color-interpolation property<br> <kbabbitt> ... not objecting, just curious about surprising behaviors<br> <kbabbitt> fantasai: why dont we make color interpolation methods optional<br> <kbabbitt> ... and have color-interpolation properthy that sets default?<br> <ChrisL> you don't get the result in a legacy colorspace, see https://drafts.csswg.org/css-color-5/#serial-color-mix<br> <kbabbitt> lea: even if down the line a better color space comes along<br> <kbabbitt> .. I think it would be good to give authors a way to set default color interpoliation space<br> <kbabbitt> ... not as simple as providing a property<br> <kbabbitt> ... because different use cases need different interpolation spaces<br> <kbabbitt> ... but I think that's right direction<br> <kbabbitt> ... also there was a concern we shouldn't try to protect authors from bad choices<br> <kbabbitt> ... ironic because we were worried in color-contrast about protecting authors from bad choices<br> <kbabbitt> ... in general I think we give sensible defaults to reduce author cognitive overhead<br> <fantasai> lea+++++++++<br> <kbabbitt> ... e.g. layout has many smart defaults so people don't ahve to understand grid intricacies<br> <kbabbitt> ... taht's why sensible defaults are a design principle<br> <kbabbitt> ... re: emilio - good point, it might be unexpected if authors did not define color space, to get oklab after specifying srgb<br> <kbabbitt> ... interpolation color space and result color space do not beed to be the same<br> <fantasai> ChrisL, why is that a problem? you opted into it<br> <kbabbitt> .. coud define color returned in color space of first arghument<br> <kbabbitt> ... we can do these things, but it's a separate decision\<br> <kbabbitt> ... e.g. what color space result is in<br> <kbabbitt> ... interpolation can still be in oklab<br> <ChrisL> qq+<br> <astearns> ack ChrisL<br> <Zakim> ChrisL, you wanted to react to fantasai<br> <astearns> ack lea<br> <kbabbitt> ChrisL: emilio - the thing you said was wrong, quoted spec<br> <kbabbitt> ... [missed]<br> <kbabbitt> emilio: if you do color-mix in oklab, red 50%, blue<br> <kbabbitt> ... you get an oklab color<br> <kbabbitt> ... that's expected since you mix in okalb<br> <lea> s/... [missed]/lea: but in color-mix() without an interpolation space, it's implicit/<br> <kbabbitt> ... but if you omit and do color mix red blue<br> <kbabbitt> ... it might be unexpected to get back oklab<br> <kbabbitt> ... if the color space was dependent on inputs this wouldn't be an issue<br> <astearns> ack florian<br> <kbabbitt> florian: agree with lea that we should separate question of serialization and interpolation color space<br> <kbabbitt> ... they don't have to be the same<br> <kbabbitt> ... we can have separate rules for serialization<br> <kbabbitt> ... if we don't want to be silent on main point because authors should think about this<br> <kbabbitt> ... and it's a point of education<br> <lea> We could even specify that before 50% you use the color space of the first color and >= 50% the color space of the second color :P<br> <kbabbitt> ... but also want to allow authors to not worry about it<br> <fantasai> :P<br> <kbabbitt> ... could give them an auto keyword<br> <kbabbitt> ... which is more inviting when you don't want to do than oklab<br> <kbabbitt> ... possibly we don't want to do that either and instead have separate value<br> <kbabbitt> ... but auto might be more discoverable<br> <kbabbitt> astearns: re: auto value - it would only make sense to add auto if there were different defaults to be used in various circumstances<br> <kbabbitt> ... if there's a single thing we're going to use in auto case, makes more sense to express it as omittable parameter<br> <kbabbitt> q+<br> <emilio> q+<br> <astearns> ack kbabbitt<br> <TabAtkins> kbabbitt: one thing just occurred to me about auto value<br> <TabAtkins> kbabbitt: if in the future we discover a color space we want to use isntead, authors dont' have to change their code<br> <TabAtkins> kbabbitt: tho i suppose that's true with the omitted vlaue too<br> <astearns> ack emilio<br> <kbabbitt> emilio: another q is, if we do this, do we want to serialize color-mix itself<br> <kbabbitt> ... if you specify color mix in oklab that may be what happens in gradients now<br> <lea> q+<br> <kbabbitt> ... do we make omission special or do we change color-mix in oklab to omit oklab as well<br> <astearns> ack lea<br> <kbabbitt> lea: I think it should be special so that down the line when we have a separate property that gets automatically applied<br> <kbabbitt> ... otherwise when they read value back they start relying on it<br> <fantasai> +1<br> <kbabbitt> ... and it's harder to change down the line<br> <kbabbitt> emilio: that's an issue regardless<br> <kbabbitt> ... if result is in oklab then you know what you used manually<br> <lea> q+ to say roundtripping<br> <kbabbitt> fantasai: [missed]<br> <kbabbitt> emilio: I don't think that makes it harder to change it, harder to rely on oklab by default<br> <kbabbitt> lea: another reason not to include color space is roundtripping<br> <kbabbitt> ... it should be easy to read value and plug back in without chaning what you have<br> <weinig> q+<br> <kbabbitt> ... once interpolation space becomes independent it becomes coupled in the value<br> <astearns> ack lea<br> <Zakim> lea, you wanted to say roundtripping<br> <kbabbitt> ... if you read it and write it back you override what was in value<br> <kbabbitt> emilio: what we would do now if we say oklab is defauklt<br> <kbabbitt> ... if you specify oklab we'd omit it<br> <kbabbitt> lea: if someone explicitly spercifies it htat's author intent<br> <kbabbitt> ... we should not just drop it<br> <kbabbitt> weinig: we would by current serialization rules<br> <kbabbitt> emilio: I don't mind either way but I think TabAtkins had strong opinions about having special values by omiision<br> <kbabbitt> ... maybe we should ahve a keyword for this even if we omit by default<br> <kbabbitt> ... don't think dropping in oklab as long as it's a default is aproblem<br> <kbabbitt> ...doesn't make it hard ot change down the line<br> <astearns> ack weinig<br> <kbabbitt> weinig: in terms of taking this idea that at some point in future we might define interpolation space property<br> <kbabbitt> ... I think that's a good reason to put this on hold until then<br> <kbabbitt> ... because if we want to do something where color mix takes on the inherited color interpolation space<br> <lea> q+<br> <TabAtkins> especially in a case like this, where the keyword is preceded by anotehr keyword, it's important to have every value explicitly writeable. Otherwise you can't write `color-mix(in var(--color-space), ...)` and have all options available<br> <kbabbitt> ... that would be just as surprising to other people<br> <kbabbitt> ... that suddenly color mixes that set interpolation space are suddenly changed<br> <kbabbitt> ... if we are going to change it and change defaults, or remove/add efaults<br> <kbabbitt> ... doing them together as a unified piece would make sense<br> <TabAtkins> (you'd have to instead write `color-mix(var(--color-space))`, and write `--color-space: in oklab`, which is awkward)<br> <kbabbitt> ... still don't think having a default here is necessaty<br> <astearns> ack lea<br> <kbabbitt> ... especially given that colort spaces evolve<br> <kbabbitt> lea: a lot of history in having knobs that people can control through CSS properties<br> <kbabbitt> ... transition-behavior; allow-discrete was one<br> <kbabbitt> ... same argument could be made about that<br> <kbabbitt> ... or size interpolation<br> <kbabbitt> ... property that tweaks how that works<br> <kbabbitt> ... that's how we frequently do things<br> <bramus> q?<br> <kbabbitt> ... if you take the effort to specify this property, anything that deoesn' have an interpolation space gets default seems reasonable<br> <bramus> q+<br> <kbabbitt> ... I don't think we should continue same current situation for a number of reasons mentioned<br> <kbabbitt> ... not just one, authors are making poor choices<br> <kbabbitt> ... potential for errors, even myself I forget to specify and am unsure why it doesn't interpolate<br> <kbabbitt> ... it's verbose<br> <kbabbitt> ... many reasons to omit this<br> <argyle> +1 lol, i've forgotten to put the colorspace in there multiple times<br> <kbabbitt> ... there should be a way to specify default<br> <kbabbitt> ... but unless you're using a var like that you shouldn't have to specify<br> <kbabbitt> ... but there should aloso be a way to specify to use a fallback<br> <kbabbitt> weinig: if we're going to add that thing, doing both changes simultaneously so authors learn would be preferred<br> <kbabbitt> astearns: in interest of time, let's take back to issue<br> <kbabbitt> ... hearing reservations<br> <lea> is anyone else actually objecting?<br> <bramus> https://github.com/w3c/csswg-drafts/issues/9109 could solve this<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11532#issuecomment-2625706594 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 22:12:49 UTC