- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 Feb 2025 17:33:56 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Interpolate values between breakpoints`, and agreed to the following: * `RESOLVED: Accept the general approach, change map naming to scale for now, iterate on syntax later` <details><summary>The full IRC log of that discussion</summary> <bramus> TabAtkins: elika and i were looking over this and there is a generic request to interpolate values based on some othe rprogeress value<br> <bramus> … can be done by hand with calc, but does not work for all values<br> <bramus> … or there are complex ways to interpolate<br> <bramus> … seem slike a reasonable thing, that if you can do atransition, you can get the value for it too<br> <bramus> … upon review of the use-case, what we were tyring in the spec was not good enough<br> <bramus> … currently not implemented, so can start over<br> <bramus> … new proposal<br> <lea> q+<br> <bramus> … two notions of interpolation<br> <scribeAssistant> Writeup is at https://github.com/w3c/csswg-drafts/issues/6245#issuecomment-2661545284<br> <bramus> … 1. mixing of two values<br> <bramus> … 2. interpolate values in series, more like linear() for timing or gradients<br> <weinig> are the existing spec'd functions the progress() functions?<br> <bramus> … both are nearly identical, but when you reach 3 values they differ a lot<br> <bramus> … can model either with the other, but frustrating and weird<br> <bramus> … prop to introduce mix and map<br> <scribeAssistant> weinig: https://drafts.csswg.org/css-values-5/<br> <bramus> … mix = …<br> <bramus> … syntax proposal in the issue<br> <weinig> q+<br> <bramus> … thoughts, ideas, …?<br> <lea> https://github.com/w3c/csswg-drafts/issues/6245#issuecomment-2685663483<br> <Rossen3> ack lea<br> <bramus> lea: posted my thoughts on this link here<br> <bramus> … when i started writing that i was not too crazy about introducing mor efunctions<br> <bramus> … wanted to overload the exsting mixing functions<br> <bramus> … but while writing my feedback it would make sens to have a new function (if it has a good name)<br> <bramus> … maps typically help you transform 1 value into another<br> <bramus> … (example)<br> <bramus> … several requests had to add mapping to css<br> <bramus> … even though sth like calc-map() or whater-map() it overloads the concept and now mapping is 2 diff things<br> <bramus> … also confusing to be using an established concept in a diffefernt way<br> <bramus> … interpolate is long and technical<br> <bramus> … brainstormed a bit (see table in comment)<br> <bramus> … leaning towards the name scale which gives a nice color-scale<br> <bramus> … and calc-scale<br> <bramus> … not ideal for images<br> <bramus> … also huge +1 for solving this use case<br> <bramus> … is major in design systems and tokens<br> <bramus> … so yeah<br> <bramus> TabAtkins: not attached to the name, we chose map bc interpolate was bad for your reasons and its also short like mix<br> <fantasai> +1<br> <bramus> … scale seems appropriate<br> <bramus> … having a hwole family of related fns the worry<br> <fantasai> We weren't particular about the name, just needed one.<br> <astearns> a little worried about our existing scale property<br> <Rossen3> ack weinig<br> <bramus> weinig: which of the css-values=5 fns is this replacing?<br> <bramus> TabAtkins: the mix functions, not the pgoress ones which are inputs to these<br> <bramus> weinig: got it<br> <bramus> … other suggestion: blend<br> <bramus> … bc that is often the result<br> <bramus> … proble with scale is that we already have scale()<br> <bramus> TabAtkins: only obj to blend is that it is a close synonym to mix<br> <lea> +1 to TabAtkins . Also `blend` sounds related to blend modes<br> <bramus> … the better we can help authors remember which is which is good<br> <bramus> lea: +1<br> <bramus> … and also bend sound related to blending modes<br> <bramus> TabAtkins: prolly cant avoid some semantic overlap<br> <bramus> Rossen3: sounds like we are converging?<br> <bramus> fantasai: yes, want to go over what it is<br> <lea> q+<br> <bramus> … the fn takes a bunch of top level params and what th eprogrsss is within the scale and a list of stops similar to linear-gradient(0 with an interpolation option between the stops (easing fn for example)<br> <bramus> … and then the top level options are a source for the progress, also giving you an option of transofmring that source thorugh an easing function, and an option saying each step gets its own easing<br> <bramus> … that is the top level<br> <bramus> … and then the stops have a syntax where it is `stop: value` and you interpolate between th stops<br> <fantasai> color: color-map(media-progress(width, 0px, 2000px),<br> <fantasai> 0%: red,<br> <fantasai> 100%: blue);<br> <fantasai> color: color-map(media(width),<br> <fantasai> 0px: red,<br> <fantasai> 2000px: blue);<br> <bramus> fantasai: also introducing new fns<br> <bramus> … percentages, pull the value out directly<br> <bramus> … pull out the start and end values, package them up together and put m in a variable<br> <bramus> … so the progress functions are worth keeping for that reason<br> <bramus> … Qs?<br> <Rossen3> ack lea<br> <bramus> lea: dont quite understand by vs each<br> <bramus> … its a good design goal to be compatible with gradients<br> <bramus> … it could even b ea design goal that everyting in side color-scale is a valid gradient<br> <bramus> … good for rease and debugging<br> <bramus> … the syntax with colons of positions adn values. not sure the reduction with the rest of CSS is warranted by the usability adv<br> <bramus> … seems small<br> <bramus> … breaking compat is a good thing if it gives you a significant advantage, not sure that is the case here<br> <bramus> … suggestion to stick to existing syntax<br> <bramus> … (missed: gradients)<br> <bramus> … where you can percentages<br> <TabAtkins> animating-timing-function vs animation-easing<br> <bramus> fantasai: diff between by and each is wehther you are applying easing between two stops or to the entiry of the progress value. Animations have this distinction. Can ease the entire timilne or in between keyframes.<br> <bramus> … have the ability to put easing between any two stops, or the whole thing upfront<br> <lea> s/(missed: gradients)/we would need to make it mandatory that the stop position comes after the value in the calc version, as otherwise there would be disambiguation problems/<br> <bramus> … that is the difference<br> <bramus> … about the colon in the stop syntax: that is bc of the parsing ambiguity<br> <bramus> … cant know the reeturn value upfront<br> <bramus> … other optino is to align with if() and use semicolons<br> <bramus> … not sure though<br> <lea> q+ to ask about multiple positions, also use cases for each<br> <bramus> TabAtkins: there are certain value types make it ambigious to read or actually ambiguious<br> <bramus> … e.g. calcs() sometimes hard to read<br> <bramus> … not obvious to a human sometimes<br> <bramus> … more problematic is the generic map() that can do entire property values<br> <bramus> … no way to know where the value ends<br> <bramus> … so have to either put the percentages in a distinguished place (like now) or only require 1<br> <bramus> … would not allow us to do 1 or 2 stops<br> <bramus> … bc those fns have parsing difficulties if you try to mix things in, we decided to carry that through the whole family of functions<br> <bramus> … making most of map fns look similar to ?? but hten some not , looks worse<br> <Rossen3> ack lea<br> <Zakim> lea, you wanted to ask about multiple positions, also use cases for each<br> <TabAtkins> s/??/mix functions/<br> <bramus> lea: agree that constiency with eachother is more imporatnt than consistency with the rest of CSS<br> <TabAtkins> 1 + 2px +3px<br> <bramus> … not sure about the color … hard to read or disambiguation issue?<br> <bramus> … for the generic no amount of syntax would work other than putting it first<br> <bramus> fantasai: (missed) progress values. can have a stripe<br> <bramus> lea: is the generic fn actually ahppening? remember we had one for mix but then had to drop it<br> <bramus> TabAtkins: multiway interpolation is trickier but if its just for map you are only interpolating two values at a time – we already know how to do that<br> <bramus> lea: this wont solve issue with generic, but at least fo rothers we coul dintroduce an at-keyword<br> <bramus> … like red at 50%<br> <bramus> … very readable<br> <bramus> TabAtkins: but unfrotunately does not extend<br> <bramus> … not the best, happy to discuss precise syntax more<br> <bramus> … looking for objections about the general approach<br> <bramus> Rossen3: so now are gonna stick with the map?<br> <lea> fantasai: no, I meant `at 50%`<br> <lea> q?<br> <fantasai> @ 50% might be kinda nice though :)<br> <fantasai> It avoids any parsing issues since @ is not otherwise valid<br> <lea> can we have a proposed resolution?<br> <bramus> TabAtkins: lets switch over to scale and continue discussing<br> <bramus> lea: do we have a proposed resolution? take on work?<br> <bramus> TabAtkins: yes: accept the approach we have outlined in the issue changing the map naming for scale and continue iterating on the design in the spec<br> <lea> PROPOSED RESOLUTION: Accept the general approach, change map naming to scale for now, iterate on syntax later<br> <bramus> Rossen3: sounds reasonable<br> <bramus> weinig: will the keyframes part remain as well?<br> <bramus> TabAtkins: that is the plan, but also up for discussion<br> <bramus> weinig: I think you should keep them<br> <bramus> fantasai: Qs for syntax were about the separator keywords by vs each and the name of the function<br> <lea> Huge +1000 to solving this problem, this is huge. Some doubts about each (do we have use cases for it?) but we can sort out later<br> <bramus> lea: +1, like I said in IRC<br> <bramus> … its low level, but lack of being able to do this keeps cropping up all the time<br> <bramus> fantasai: yes, need to thank scott for filing this and following up on it<br> <bramus> Rossen3: Objections?<br> <bramus> … none, so we are resolved.<br> <bramus> RESOLVED: Accept the general approach, change map naming to scale for now, iterate on syntax later<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6245#issuecomment-2685746280 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 26 February 2025 17:33:57 UTC