- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Dec 2023 00:25:49 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-values] Abandon mix()?`, and agreed to the following: * `RESOLVED: Drop mix() from Values 4` * `RESOLVED: we will never use mix to represent a single interpolated value but may have something like it for expressing the whole interpolation` <details><summary>The full IRC log of that discussion</summary> <dael> TabAtkins: First off, to clarify. Since issue was filled mix() gained a new syntax. We're not talking about that. This is about dropping original feature for mix(). It was intended to let us represent values that couldn't be written as computed but do interpolate<br> <dael> TabAtkins: Since then we added sufficient specialized functions to values 5 to handle all cases we know where this happens. Only a handful of cases that needed the generic interpolation.<br> <dael> TabAtkins: So, I believe we can drop the generic interpolator and stick with the specific ones that handle each thing that needs special behavior<br> <dael> florian: And it did not represent things that are not interpolable?<br> <dael> TabAtkins: Correct, it was invalid syntax<br> <dael> fantasai: Two reasons mix was added. One was for these interp that you can't show intermediary value. Other was create syntax to allow authors to represent an interpolation of a value between two breakpoints in a MQ. It's not that the intermediary can't be represented but it's because you want a range depending on another calc<br> <miriam> q+<br> <dael> fantasai: That's what mix was originally for. Since then, TabAtkins and I decided it should be kicked from level 4. But the other function of mix where you can take a whole property value and interpolate between it and another value based on how far you are in a 800px window<br> <dael> florian: And you could represented it but not well?<br> <astearns> ack miriam<br> <dael> fantasai: You could, but now that there's calc-mix you can represent. But if you have something like descrete keywords you can't unless there's an existing mix value<br> <dael> miriam: You've basically answered my question.<br> <dael> TabAtkins: They cover the case for the types they're meant for. There's a bunch of types like keywords that don't have a mix function<br> <dael> miriam: That use case feels useful to me<br> <dael> fantasai: I think there are reasons to want something like mix. I don't think we want to impl as is. Reasonable to resolve not in L4 but seems reasonable to explore<br> <dael> TabAtkins: Also resolve that we're not intending mix to represent intermediate values would be good. But intent that it's useful for authors to say somewhere on this path is good. Good to resolve that we're not keeping mix to rep intermediate values<br> <dael> astearns: Prop: We will drop mix from L4. Specifically, we don't want to use it for the generic representation of interpolated values but we may in a future level come up with something like mix to express the interpolation itself<br> <dael> fantasai: 2 resolutions. Drop mix from Values L4. Second is: Keep exploring mix for interpolation use cases but not for representing a single interpolated value<br> <TabAtkins> proposed: we're not keeping mix() *for the purpose of representing intermediate values*. keeping it for *authors wanting to interpolate arbitrary things* is still on the table<br> <dael> astearns: First part, drop mix from Values 4. Obj?<br> <dael> RESOLVED: Drop mix() from Values 4<br> <dael> astearns: Second is we will never use mix to represent a single interpolated value but may have something like it for expressing the whole interpolation<br> <dael> fantasai: It shouldn't be the only way to represent the value<br> <dael> RESOLVED: we will never use mix to represent a single interpolated value but may have something like it for expressing the whole interpolation<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9343#issuecomment-1843933577 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 7 December 2023 00:25:52 UTC