- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 15 Sep 2023 09:03:01 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-fonts-5] Proposal: Animating font-palette`, and agreed to the following:
* `RESOLVED: add palette-mix(), bikeshed on the issue about the interpolation color space`
<details><summary>The full IRC log of that discussion</summary>
<fremy> drott: in a previous call, we made a presentation where we animated font color palettes<br>
<fremy> drott: we would like to extend the list of animatable properties with this<br>
<myles> q+<br>
<fremy> drott: we are motivated by requests by type foundries and some authors<br>
<fremy> drott: our proposal is to add a palette-mix function<br>
<fremy> drott: similar to color-mix<br>
<fremy> drott: this is mostly need to represent the result as a value, but not sure this is needed for authors otherwise<br>
<fremy> drott: you would just transition from one to another<br>
<fremy> drott: but if you are interested in the computed value, this is what you get<br>
<fremy> drott: for completeness, you can probably nest them<br>
<chris> q+<br>
<ntim> q+<br>
<fremy> drott: this function should be added as a potential value for the font-palette proporty<br>
<fremy> drott: we have a working draft edit already<br>
<fremy> drott: chris and TabAtkins reviewed this, and the feedback was positivie<br>
<miriam> ack myles<br>
<fremy> drott: we would like to resolve on it<br>
<TabAtkins> q+<br>
<fremy> myles: is the function truly necessary?<br>
<fremy> drott: to represent the computed value<br>
<emilio> q+<br>
<fremy> myles: do people want that computed value?<br>
<fremy> drott: I think not to do this, why would font-palette be different?<br>
<fremy> drott: also, you need an internal representation of this anyway<br>
<fremy> TabAtkins: usually, we can't animate things that cannot be represented<br>
<fremy> myles: we can in theory do this<br>
<TabAtkins> ack TabAtkins<br>
<miriam> ack chris<br>
<fremy> TabAtkins: yes, but that would not be among the things the spec allows<br>
<fremy> chris: I like that this looks like color-mix<br>
<fremy> ntim: what is the difference between mix and palette mix?<br>
<fremy> chris: mix does not allow to specify color spaces<br>
<astearns> ack ntim<br>
<emilio> q- later<br>
<fremy> ntim: what about the default color space?<br>
<astearns> q+<br>
<emilio> q-<br>
<fremy> drott: at the moment, if you go from or to, it goes from/to the default, which is the one from the font<br>
<miriam> ack ntim<br>
<fremy> ntim: what if there was a mix just for color spaces, what about a more general purpose mix function?<br>
<fremy> chris: the issue with mix(...) is that it's difficult to implement<br>
<dbaron> (looks at the existing color-interpolation property...)<br>
<TabAtkins> We'll talk about mix() later, but ntim was asking about a general color-interpolation control, not mix()<br>
<astearns> q-<br>
<fremy> chris: while palette-mix is easy to understand<br>
<fremy> ntim: I don't think you can you set a color-space just for that animation<br>
<fremy> ntim: if mix was implemented, would that solve the problem?<br>
<dbaron> https://svgwg.org/svg2-draft/painting.html#ColorInterpolation<br>
<fremy> chris: in theory mix is nice, but it's difficult to track all the dependencies<br>
<dbaron> (I'm not saying this is what we want, but we do already have a global color interpolation control property)<br>
<fremy> ntim: what about a color-space-animation property?<br>
<TabAtkins> Yes, mix() is just *precisely* what the `from { prop: start; } to { prop: end; }` behavior is.<br>
<fremy> drott: that would be another thing, I'm not opposed<br>
<fremy> drott: what you can do today is the use the function and animate the percentage<br>
<fremy> chris: (missed) would be more complicated and would not be moving as fast<br>
<miriam> ack dbaron<br>
<fremy> chris: I see the point about generality, but I think this isn't the best strategy forward<br>
<myles> q+<br>
<fremy> dbaron: if we wanted a global color mixing function, and we should add these things on the same place rather than duplicate<br>
<miriam> ack myles<br>
<fantasai> s/and we should/there's a color-interpolation property in SVG. We should/<br>
<TabAtkins> We *could* just use the property name and deprecate/remap the old values if needed. We did that for image-rendering<br>
<fantasai> +1<br>
<dbaron> s/if we wanted/not saying we want to, but if we wanted/<br>
<fremy> myles: from what I understand, the computed value shoud not create new at-rules<br>
<fremy> myles: so, we have to express this in a mix<br>
<fremy> myles: we already have this in font-features<br>
<fremy> myles: do we need a font-features-mix() function?<br>
<fremy> chris: aren't those things you should just flip<br>
<fremy> myles: but they could be animatable in theory?<br>
<fremy> myles: if so, where do we stop?<br>
<astearns> glancing at https://developer.mozilla.org/en-US/docs/Web/CSS/@font-feature-values they do look discrete<br>
<fremy> drott: the concrete question is answered that these are discrete and not animatables<br>
<chris> s/(missed)/colorspace-aware transitions<br>
<fremy> drott: for the more abstract question, I don't foresee an explosion of mix functions in the future<br>
<fremy> myles: we already have three<br>
<fremy> drott: we could not come up with a more minimal syntax, also<br>
<fremy> myles: I'm not gonna block this, but I would like to be on the record that I don't think this is the best idea<br>
<fremy> TabAtkins: just to clarify more<br>
<fremy> TabAtkins: font-features cannot be animated, so the question there is moot<br>
<fremy> TabAtkins: font-variant values would be, but the animation is discrete, you cannot interpolate<br>
<fremy> TabAtkins: so, we will add custom interpolation functions if you have values, which you need to smoothly interpolate, and you cannot represent the internals<br>
<fremy> miriam: what about just tell the colors?<br>
<emilio> q+<br>
<fremy> TabAtkins: an unnamed palette does not exist now, so we would have to add this<br>
<astearns> s/miriam/astearns/<br>
<fremy> TabAtkins: sounds more work<br>
<astearns> finally understands why color-mix() is insufficient<br>
<fremy> myles: the value space of a shorthand is a smaller space then you cannot get as an empty string because the shorthand is out of the value space of the property<br>
<fremy> myles: I view this case as similar<br>
<miriam> ack emilio<br>
<fremy> TabAtkins: one big difference is that you can get the value with the longhands<br>
<fremy> TabAtkins: here you just cannot anymore<br>
<fremy> emilio: you will need this internally anyway<br>
<fremy> emilio: adding code to parse it is not much more work<br>
<fremy> myles: but still, the use case does not warrant this effort, is my claim<br>
<TabAtkins> Counter is that the CSS model *does not allow* animating without being able to obtain a computed value of the interpolation.<br>
<fremy> emilio: if there is a longhand which you cannot serialize in any way, I think this can yield to problems<br>
<fremy> myles: what about shorthands?<br>
<fremy> emilio: but authors can limit themselves to longhands<br>
<fremy> myles: but if they use the longhand, it still does not roundtrip<br>
<fremy> emilio: I think it would be bad to not have a value for this<br>
<fremy> emilio: to me, this seems reasonable<br>
<fremy> emilio: that said, how would you describe the color space interpolation<br>
<fremy> emilio: if you have the function, you can add parameters<br>
<chris> I agree that is is important that this animation fits the general CSS animation model. It also means scripts using web animations will work with this<br>
<fremy> drott: like I said, you only that if you need to downgrade the color space<br>
<fremy> drott: by default, we will do the highest quality interpolation<br>
<TabAtkins> yeah, a lab vs lch interpolation is still useful to switch while still being high-quality<br>
<fremy> emilio: or change the type of interpolation (hsl, or sRGB)<br>
<TabAtkins> and in lch, controlling interpolation direction is important<br>
<fremy> emilio: it feels a bit not-amazing<br>
<fremy> drott: we could standardize this<br>
<astearns> ack dbaron<br>
<emilio> q+<br>
<fremy> dbaron: I just wanted to agree that having some sort of value to represent the interpolated value is what you need to do to fit the model of CSS Animations<br>
<ntim> +1 to dbaron and emilio<br>
<fremy> dbaron: and not having this convertable to a string would be unique<br>
<TabAtkins> (We have one example of an unrepresentable computed value right now - some transforms can trigger this. We invented mix() specifically to solve that case.)<br>
<chris> +1<br>
<fremy> dbaron: and that would break many assumptions<br>
<fremy> miriam: are we moving towards a resolution here?<br>
<fremy> emilio: just need a follow-up<br>
<fremy> emilio: do we believe that people will want to do the color space change<br>
<TabAtkins> If needed, we can resolve "add palette-mix(), but might change our mind after our later discussion on mix() itself"<br>
<fremy> emilio: can we add a new argument for that?<br>
<miriam> q?<br>
<miriam> ack emilio<br>
<fremy> emilio: in your animation, you could specify from and to that way<br>
<fremy> chris: I think people like to have the flexibility, and I would prefer to keep it<br>
<fremy> emilio: but are we expecting people to use this? do we really need it?<br>
<fremy> chris: you would also animate ... currentColor ...<br>
<fremy> astearns: we don't have time to go into another rabbit hole<br>
<fremy> myles: ok, I'm not going to stand in the way<br>
<fremy> drott: can we take a resolution to take up the PR?<br>
<ntim> proposed: add palette-mix(), bikeshed on the issue about the interpolation color space<br>
<fremy> astearns: I think this is the right approach<br>
<fremy> emilio: I would like to resolve we need a value for this<br>
<fremy> emilio: but maybe we could still bikeshed the details of the value<br>
<fremy> ntim: I pasted a proposed resolution<br>
<TabAtkins> Yeah I'd prefer to not have a PR floating<br>
<fremy> chris: can we do this by landing the PR and opening a new issue?<br>
<fremy> miriam: ok, so, landing the PR and keep bikesheeding?<br>
<fremy> RESOLVED: add palette-mix(), bikeshed on the issue about the interpolation color space<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8922#issuecomment-1720930646 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 15 September 2023 09:03:04 UTC