Interpolate values between breakpoints

[scottkellum]

Allow interpolation between both viewport and element breakpoints.

The problems with clamp(), min(), and max() is that you can only interpolate length values on a single property between two points. You may want to interpolate rulesets across multiple breakpoints. You may also want to interpolate things like variable font settings, color, etc. Additionally it would be nice to be able to ease how breakpoints are interpolated as rates at which things scale across different screen or element sizes can often be variable.

Update Dec. 7, 2022

I’ve created an explainer on this issue with a more detailed proposal: https://css.typetura.com/ruleset-interpolation/explainer/

This includes a more specific and detailed proposal as well as a companion proposal to expand scroll timeline. Expanding scroll timeline is likely the easiest solution at the moment but it would make it more user friendly to allow length values as keyframes. This can always be added at a later date though.

[mirisuzanne]

Yeah, this would be real useful for something like "intrinsic typography" - but I can imagine other use-cases as well. It's interesting to think about media/container "breakpoints" as keyframes in an animation, which we can then interpolate (with easing).

My immediate association is scroll-timeline. I wonder if there would be a way to adapt something similar to get, basically, a container-timeline.

[fantasai]

@mirisuzanne and I put together this proposal for defining and using query-linked timelines as part of rethinking various features for animation timelines and interpolation and how to fit them all together.

Query-linked Timelines

Query-linked interpolation uses a set of keyframes (minimally, two) to interpolate values along an easing curve based on the value of a query (such as a media query or container query). The timeline is therefore defined by the value of the query, and can be referenced by an interpolation function in individual property declarations.

Defining the Query Timeline

The @timeline rule defines a named timeline. It can be expanded later to define other types of timelines, but here we're defining only two types: media query timelines and container query timelines.

@timeline NAME {
  type: media | container;
  feature: <media-feature-name> | <container-feature-name>;
  from: <value>; /* 0% of the timeline */
  to: <value>; /* 100% of the timeline */
  container: <'container'>; /* only applies to container query timelines,
                               same seeking function as container queries */
}

A typical example might look like:

@timeline font-size-timeline {
  type: media;
  feature: width;
  from: 20em;
  to: 60em;
}

While query-linked timelines can be referenced in animation-timeline, it's not recommended to use this method in most cases because it would cause cascading problem: anyone using query-based interpolation via animation properties would override all affected properties at levels of the cascade.

They can, however, be referenced by an interpolation function within the affected property declarations, which allows the interpolated value to cascade the same as any other declared value.

Value Interpolation

Value interpolation uses a percentage value to indicate how close or far from the start/end points to calculate the interpolated value. Interpolation is interpreted through an easing curve, and the input percentage can be selected based on the current position on a timeline such as a query timeline.

Timeline-based Value Interpolation

This extends the generic interpolation function adopted (but as yet unnamed ;) in #581

  mix( [ <timeline> && [ by <easing-function> ]? ] ; <start-value> ; <end-value>)

By naming a timeline instead of giving a percentage directly (see percentage mixes in #581 (comment)), the author can use progress along a timeline as the progress percentage. Any value valid for animation-timeline or any timeline name defined via @timeline is valid, which allows the mix() to respond to query-linked timelines and scroll-linked timelines.

Value Interpolation with Keyframes

For more complex interpolation curves, the <start-value> and <end-value> can be replaced by a reference to a named set of keyframes.

  mix( [ <timeline> && [ by <easing-function> ]? && of <animation-name> ] )

Note: Using keyword markers (as in gradients) allows the arguments to be reordered, so that authors don't have to memorize positions of arguments.

[bramus]

A typical example might look like:

@timeline font-size-timeline {
  type: media;
  feature: width;
  from: 20em;
  to: 60em;
}

As an addendum: for CSS @scroll-timeline — as specced in the Scroll-Linked Animations spec — the authors explicitly moved away from using start (here named from) and end (there named to) as descriptors.

They replaced it with one descriptor named scroll-offsets (which here could be named offsets), that accepts an array of values.

As per spec:

Scroll timeline offsets determine the effective scroll offsets in the direction specified by orientation that constitute the equally-distanced in progress intervals in which the timeline is active.

That way they allow more than two offset to be used.

Relevant Issue: #4912, specifically this comment.

[mirisuzanne]

@bramus If I understand right, we're thinking about timelines a bit differently here. They seem to be establishing the number and placement of keyframes in the timeline description, and that seems to me like the wrong location for that information.

In our proposal, the timeline doesn't establish the available keyframes, just the distance that we travel from 0% complete to 100% complete. Then authors can attach that to an animation or interpolation function with as many keyframes as they need. The individual offset concerns of each animation ("reveal, "unreveal", etc) are handled in keyframes, rather than in the timeline itself. So you have a single timeline (x to y), and then the ability to offset keyframes within that timeline. "Reveal" might happen between 20%-40% of the timeline, and "unreveal" happens from 60%-80%, each one using as many keyframes as it wants.

The number and placement of keyframes is controlled by the animation/interpolation rather than by the timeline.

But maybe I'm misunderstanding something there?

[bramus]

@mirisuzanne You understand correctly there. Simply wanted to point out that “this move in the other direction” was made before, and that it perhaps could be relevant to take into account ;)

[css-meeting-bot]

The CSS Working Group just discussed interpolating values between breakpoints, and agreed to the following:

• RESOLVED: Accept mix() function into Values 5

The full IRC log of that discussion

<TabAtkins> Topic: interpolating values between breakpoints
<TabAtkins> github: https://github.com//issues/6245
<fantasai> https://github.com//issues/6245#issuecomment-926351855
<TabAtkins> miriam: This is building on that same idea, but creating timelines out of MQ/CQs
<TabAtkins> miriam: In this caes you're more often doing interpolated values based on the timeline, not animations specifically
<flackr> q+
<TabAtkins> miriam: We want to be able to create timelines off the size of the container
<TabAtkins> miriam: So for defining the query timeline, we have an @timeline syntax.
<smfr> q+
<TabAtkins> miriam: Give it a name, say what we're querying, what feature we're querying
<TabAtkins> miriam: And give it a from/to value to offset that range
<TabAtkins> miriam: So interp between a container being 100px and 40em to define the timeline
<TabAtkins> miriam: If it's a CQ we give the name of the container
<TabAtkins> miriam: If there are multiple CQs with that name this'll apply to all of them
<TabAtkins> miriam: Kids will look at their appropriate ancestor container
<TabAtkins> miriam: And we can use the timeline name in an animation-timeline
<TabAtkins> miriam: But more often we'll want a value that interps in the cascade instead, so we can override it if we need to
<TabAtkins> miriam: A generic interpolate() function has been discussed for a long time
<TabAtkins> miriam: We called in mix() here, named TBD
<TabAtkins> miriam: Idea is it could be generic, taking a %, or take a timeline which resolves to a %. Could invoke scroll timelines too, etc.
<TabAtkins> miriam: And then it takes an easing function and two values to interp between
<TabAtkins> miriam: In some cases this'll get more complex with multiple values, maybe get quite long
<TabAtkins> miriam: Wondered if mix() could ref keyframes
<TabAtkins> miriam: So you could pull out the value details into keyframes for more detailed control
<TabAtkins> fantasai: I wanted to point out the cascade effects
<chris> q+ to wonder about once more doing piecewise functions with no continuity
<TabAtkins> fantasai: We considered putting query-based timelines as a value of aniamtion-timeline
<TabAtkins> fantasai: That ends up applyin all the props at once, and at an overriding level of the cascade
<TabAtkins> fantasai: Usually you don't want that, you just want to specify a value at a normal cascade spot, but *based on* a timeline
<TabAtkins> fantasai: So my font-size timeline can just spec an interpolated normal font size, and then have an overriding rule setting the font-size to a specific value as normal.
<Rossen_> ack fantasai
<Zakim> fantasai, you wanted to react to flackr to point out cascade effects
<Rossen_> ack flackr
<fantasai> s/as normal/as usual in the cascade/
<TabAtkins> flackr: I think what fantasai just said might change my q...
<TabAtkins> flackr: So this isn't an animation timeline, it only exists for the mix() function?
<TabAtkins> fantasai: We were debating that.
<TabAtkins> fantasai: We definitely want it for mix(). Whether it's available for animation-timeline is an open question
<TabAtkins> fantasai: We've asked brian for feedback and he pointed out there were a lot of complexities, so we might not want to do it
<TabAtkins> fantasai: Not the most important; mix() is the primary case
<TabAtkins> flackr: Yeah was gonna raise the same complexities; if it's animation, we have to have the animation progress update in the middle of the cascade.
<TabAtkins> flackr: Anders said it would be a huge technical burden to have anims update as part of the cascade due to the cascade
<TabAtkins> smfr: This feels like calc() to me
<Rossen_> ack smfr
<TabAtkins> smfr: We could have one that interps with easing funcs
<TabAtkins> smfr: Missing piece is input from media features, could come in as env()
<TabAtkins> smfr: And so with a calc easing function thing
<fantasai> TabAtkins: not quite, implies only doing calc()-able things
<fantasai> TabAtkins: not all things that can be interpolated
<fantasai> TabAtkins: which includes colors, etc.
<fantasai> smfr: Can we make calc() accept these things?
<fantasai> TabAtkins: I don't want to but we can talk about it?
<Rossen_> ack chris
<Zakim> chris, you wanted to wonder about once more doing piecewise functions with no continuity
<TabAtkins> chris: So this is unpopular
<TabAtkins> chris: We start by lerping two values
<TabAtkins> chris: Then we add more values and lerp them
<TabAtkins> chris: And if you draw that it's jaggy on a graph because slopes are different
<TabAtkins> chris: And then we add easings, and you can maybe fake it to look continuous
<TabAtkins> chris: But we never get to a thing that smoothly interpolates thru N values
<TabAtkins> chris: Is that something we want to do or just continue keeping it pairwise?
<TabAtkins> flackr: Is this not having easing on the mix function?
<TabAtkins> chris: That requires the author to figure out C1 continuity on their own
<TabAtkins> fantasai: This seems compatible with what keyframes do right now, we could default to smooth interp
<TabAtkins> TabAtkins: So chris's request is for the abilty to spec an animation with N values and have it automatically smoothly interp, rather than only having pairwise interp control that needs manual adjustment
<TabAtkins> chris: yes
<TabAtkins> TabAtkins: c1 continuity, to be specific
<fantasai> fantasai: We specced multi-stop animations using @Keyframes, see last section of proposal
<Rossen_> q?
<fantasai> TabAtkins: I suspect that's something we can handle at a higher level
<fantasai> TabAtkins: we have a default for pairwise interpolation, default to ?
<fantasai> TabAtkins: could do smarter things in animations
<fantasai> TabAtkins: fits within existing syntax structure of animations
<fantasai> flackr: It will be challenging, though
<fantasai> flackr: easing function per keyframe is just between those endpoints
<fantasai> flackr: easin function on animation is just input time to output time
<fantasai> TabAtkins: animation-easing-function is the default between frames
<fantasai> flackr: that's correct for CSS. Web Animations also adds an easing curve to the timeline
<fantasai> TabAtkins: you're easing time into massaged version, that's separate from this
<Rossen_> ack fantasai
<TabAtkins> fantasai: i think we could easily have a "tweak the time"-based version, we could add that into the rule as well
<fantasai> s/rule/@timeline rule/
<fantasai> fantasai: Intention of mix() argument was the default easing between frames
<fantasai> fantasai: If we want to default to doing continuous magic, or adding a keyword to opt into it, that's fine
<TabAtkins> flackr: Yeah it would be like combining adjacent pairs that have the same value into one continuous timing function
<TabAtkins> fantasai: I want to point out we dont' ahve a resolution on the form of the generic interp function
<TabAtkins> fantasai: So our proposal is to have it accept %s and two values
<fantasai> https://github.com//issues/581#issuecomment-926353789
<TabAtkins> fantasai: So this would be a function that replaces the % with a timeline that computes to a %
<TabAtkins> fantasai: We have a resolution to *add* a mix() function but didn't settle on the syntax
<TabAtkins> Rossen_: So what can we resolve on?
<fantasai> s/this would be/this proposal is/
<TabAtkins> fantasai: resolution the first: generic interpolate function is called mix(). Takes %, then start value, then end value. Values are separated with semicolons to avoid ambiguity with comma-containing values
<TabAtkins> (you can interp a comma-separated list, for example)
<TabAtkins> TabAtkins: Simon had some thoughts about this in calc(), do you want to continue talkinga bout this?
<TabAtkins> smfr: I'm not quite sold on @timeline yet, but I don't want to stall this
<fantasai> https://github.com//issues/581
<TabAtkins> fantasai: Right now it's just mix()
<TabAtkins> smfr: Would this be like a calc()?
<TabAtkins> fantasai: Like, but wider.
<fantasai> fantasai: It has to be able to interpolate every possible computed value in the entire space of CSS
<TabAtkins> smfr: It requires UAs to have a parallel version of calc trees, for every possible value
<TabAtkins> fantasai: You kinda already have that since everything can interp
<TabAtkins> fantasai: Like, how do you interp between currentcolor and blue? No way to represent that right now. (color-mix() is coming, but this is a wider issue)
<TabAtkins> fantasai: So we have lots of places where we want to interp things that don't have intermediate values
<TabAtkins> smfr: That makes sense, we also invented cross-fade() to hit the image case
<TabAtkins> smfr: I'd like to hear from other impls about their thoughts on impl complexity, and whether it makes sense to think of it in terms of calc()
<fantasai> TabAtkins: I don't have problem of thinking about it in terms of calc(), can re-use machinery there
<fantasai> TabAtkins: but I think that's an internal detail
<TabAtkins> fantasai: Note that we *resolved* to add the function years ago but didn't resolve on the syntax
<fantasai> see also https://github.com//issues/2854
<TabAtkins> RESOLVED: Accept mix() function into Values 5
<Rossen_> s/Accept mix() function into Values 5/Accept mix() function into Values 4/
<TabAtkins> fantasai: So next is do we want mix() to accept a timeline+easing function instead of a %
<TabAtkins> fantasai: If no, I don't need to go into details. If yes, we'd use the @timeline rule discussed previously.
<TabAtkins> TabAtkins: This just got proposed last week, it's a little big. I'd like more time to review on it.
<TabAtkins> fantasai: And this would def go into level 5
<fantasai> ScribeNick: fantasai

[scottkellum]

I have updated this issue with a more detailed explainer containing a proposal. Here is the explainer.

[danielsakhapov]

Hello, everyone!

Since we now have scroll- and view-timelines, maybe it makes sense to do something similar for this problem?
Like, container-timelines? They will allow to drive a regular CSS/Web animation using the size of a query container’s content-box.

A container timeline is created similarly to how a scroll/view-timeline is created:

#container {
  container: mycontainer inline-size;
  container-timeline: mytimeline inline-size;
}

And then the animation is set up as you would set up a scroll/view-timeline:

#target {
  animation: anim auto;
  animation-timeline: mytimeline;
}

And keyframe offsets will accept <length> values. The following defines an animation that takes place between 40em and 800px:

@keyframes anim {
  40em {
    color: green;
  }
  800px {
    color: red;
  }
}

So, overall:

container-timeline-name: #<dashed-ident>
container-timeline-axis: #[ block | inline | x | y ]
container-timeline-range: #[ <length> <length> ]
container-timeline: #[ <container-timeline-name> [ <container-timeline-axis>? || <container-timeline-range> ] ]

With container-timeline-range being min and max lengths for the progress of the animation.

[bramus]

I’m very much sold on the idea.

Two remarks though:

1. For ScrollTimeline/ViewTimeline the range is not part of the Timeline; there are no view-timeline-range or scroll-timeline-range properties. Instead, the range part of the animation, using the animation-range property. That way one can re-use one timeline instance for multiple animations with different ranges.

   I would suggest to do the same for container timelines.

2. ScrollTimeline and ViewTimeline also have anonymous timelines, via the scroll() and view() functional notations. Ideally there should also be an anonymous container timeline.

   Strawperson proposal is to name it container(), with this syntax:

   <container()> = container( <axis>? )
   <axis> = block | inline | x | y
   

   An anonymous container timeline would always look up the nearest container in the ancestor tree. The default value for <axis> is block.

[andruud]

For ScrollTimeline/ViewTimeline the range is not part of the Timeline;

It very much is, it's just that it's set automatically from min/max scroll (etc) for those. The animation attachment range is not the same thing as the timeline range itself. Notice how animation-range-start/end:normal refers to the start/end of the timeline. Without container-timeline-range, we'd need another way of understanding the start/end.

[bramus]

Ah yes, I see now why one would need to define the container-timeline-range, because unlike scroll-timeline and view-timeline it cannot be automatically determined for containers. Thanks, @andruud.

[danielsakhapov]

Sorry, I forgot about the functional notation. Container timeline can be created directly with a functional notation.
The following creates a timeline from the nearest inline-size container:

#target {
  animation: anim auto;
  animation-timeline: container(inline-size);
}

[mirisuzanne]

There was also some discussion about providing a built-in mixin that would shortcut something like this - maybe without relying on the animation origin. Maybe something like…

h1 {
  @apply keyframes(h1, container-progress(inline-size, 20rem, 60rem));
}

[scottkellum]

@mirisuzanne In this example, is easing also available?

h1 {
  @apply keyframes(h1, container-progress(inline-size, 20rem, 60rem), ease-in-out);
}

[mirisuzanne]

I would expect easing, yes. I don't think anyone has worked on a full proposal for this yet.

[tabatkins]

After talking thru the problem space and existing functions again, @fantasai and I have come up with an amended proposal for the *-mix() family of functions. As the *-mix() stuff hasn't been implemented yet, ripping it all out should be fine. ^_^

The fundamental disconnect is that there are two distinct notions of "mixing" being employed in these conversations, which look basically identical when you only have two values but are cleary distinct when you have 3+: are you "mixing" multiple values into one according to varying percentages, or are you "interpolating" (we'll use the term "mapping") between multiple breakpoints, with only two values being mixed at any given time? These two require completely different approaches when there are 3+ values. You can emulate either behavior with the other, but it's somewhere between annoying and untenably complicated.

Mixing Functions

The existing color-mix() and cross-fade() functions are the former: an unbounded number of values all combined with varying weights. As these are already implemented, we chose to leave them alone, and let the more general category of "functions like this" be called *-mix().

The general *-mix() grammars will follow the pattern:

foo-mix( <foo-specific-options>, [ <output-value> && <percentage>? ]# )

<foo-specific-option> are things like <color-interpolation-method> for color-mix(). Not all functions will have that. The <output-value> is specific to the function too; for color-mix() it's <color>. If the value type isn't distinguishable from <percentage> (like in calc-mix()), then we remove the &&, requiring the percentage to be second.

If any percentages are missing, they equally distribute the leftover percentage needed to add to 100% (floored at 0%); if the they add up to more than 100%, we rescale them to equal 100%; if they add to less than 100% we imply an additional "neutral" value with the remaining %. (For color-mix() it's transparent; for cross-fade() it's a transparent image with no natural dimensions; for calc-mix() it would be zero in the appropriate unit; etc)

Mapping Functions

For the "multiple breakpoints" case, we propose to introduce a *-map() family of functions. The existing gradient functions and linear() provide examples of this concept, but to accomodate more arbitrary values we have to generalize it a bit:

foo-map(<progress-and-top-level-options>, <stop>, [ [ <interpolation-options>, ]? <stop> ]#?)

expanding these out it looks like this:

foo-map(<progress-source> && [by <easing-function>]? && [each <easing-function> ]? && <foo-specific-option>?,
   <progress-value>{1,2} : <output-value> ,
  [ 
    [ <easing-function> || <foo-specific-option> , ]?
    <progress-value>{1,2} : <output-value> ,
  ]#?
)

where for the top-level options:

• <foo-specific-option> is same as for *-mix(): <color-interpolation-method> for color-map(), etc
• <progress-source> is a <number> or dimension, or a literal percentage (treated as an equivalent number)
• by <easing-function> eases raw progress-source value directly, using the first/last stops to define the [0,1] range it's eased over (linear, if omitted)
• each <easing-function> gives a default for the easing function between stops (linear, if omitted) so you don't have to repeat it each time

and for the stop list:

• an <easing-function> between stops gives the easing behavior just between those stops (and can have function-specific options, too, like a longer hue just between two stops while the rest use the default)
• <progress-value> is of the same type as the <progress-source>. Literal percentages are allowed (100% treated the same as 1).
• two <progress-value>s in one clause are same as in gradients or linear(): they provide two stops with the same output value, creating a stretch with a constant value

To map across media/container queries, we introduce new media/container functions that return lengths/etc (in addition to the previously adopted media-progress()/etc, which turn the length/etc into a progress number 0-1):
* E.g. media(<media-feature>), container(<container-feature>)
* These allow using the start/end/stop values directly in *-map()'s stop lists, instead of requiring conversion to percentages up front.

Some use cases will prefer using the feature output directly, while others might prefer conversion to percentages using the -progress() variants. For example, both of these are valid/allowed:

color: color-map(media-progress(width, 0px, 2000px),
                 0%: red,
                 100%: blue); 
/* allows putting the percentage scale into a variable, 
   but awkward to read/write literally, especially with 3+ stops */


color: color-map(media(width),
                 0px: red,
                 2000px: blue); 
/* easier to read/write literally, 
   but can't extract the scale into a variable */

Regarding the generic whole-value mix() function, we're proposing to:

• Rename it to map(), and give it the general *-map() syntax.
• Retain the alternative syntax <progress-source> of <'animation-name'> for map(), which takes the progress/output clauses from @Keyframes (and synergizes nicely with [scroll-animations-1] Allow <length-percentage> in <keyframe-selector> when combined with <timeline-range-name> #10000)

[tabatkins]

@scottkellum's example could be written as:

h1 {
  font-size: map(container(inline-size) from h1 by ease-in-out);
  color: map(container(inline-size) from h1 by ease-in-out);
  line-height: map(container(inline-size) from h1 by ease-in-out);
  /* all these are identical, so it could be put in a variable to reduce duplication */
}

@keyframes h1 {
  20rem {
    font-size: 1rem;
    line-height: 1.2;
    color: lime;
  }
  40rem {
    color: aqua;
  }
  60rem {
    font-size: 5rem;
    line-height: 1;
    color: hotpink;
  }
}

/* alternately, can keep the %s in @keyframes, 
   and use `map(container-progress(...))` to allow setting the scale with variables */

Or, if you did want to write them inline rather than grouping into a keyframes:

h1 {
  --scale: container(inline-size) by ease-in-out;
  font-size: calc-map(var(--scale), 20rem: 1rem, 60rem: 5rem);
  color: color-map(var(--scale), 20rem: lime, 40rem: aqua, 60rem: hotpink);
  line-height: calc-map(var(--scale), 20rem: 1.2, 60rem: 1);
}

which is probably a lot more understandable anyway.

[bramus]

(#) After talking thru the problem space and existing functions again, @fantasai and I have come up with an amended proposal for the *-mix() family of functions.

I really like this proposal. Splitting it all in mix and map seems so obvious in hindsight.

As for the names: I see you are using calc-mix() and calc-map(). Naming the functions value-mix() and value-map() feels more natural to me, as you are mixing and mapping values. This aligns with the existing color-mix(), in which you mix colors.

[mirisuzanne]

@bramus I'm confused: colors are also a kind of value, the way we use that word in CSS. I think the calc-* variants are limited to mixing calculations specifically, similar to color-mix being limited to colors. Neither one is generic for handling arbitrary CSS values of any type.

I like the proposal.

[bramus]

I'm confused: colors are also a kind of value

That‘s exactly my point.

It’s mentioned that color-mix() is a more specific version of the suggested *-mix() function, similar to how <color> is a specific type of value. So if colors get mixed with color-mix(), then (untyped) values gets mixed with … value-mix(), no?

[ydaniv]

I like this proposal, feels more intuitive.

Just not sure I understood the each <easing-function> part. IIUC by is for easing the entire range, and each for easing per breakpoint? Kind of like animation-easing and animation-timing-function?

[scottkellum]

@tabatkins This proposal seems just about perfect. I’m curious if there are any ways to use map() everywhere and either pass in the unit type or infer it.

This still doesn’t feel quite right, but maybe something like:

h1 {
  --scale: container(inline-size) by ease-in-out;
  font-size: map(var(--scale), 20rem: 1rem, 60rem: 5rem, <length>);
  color: map(var(--scale), 20rem: lime, 40rem: aqua, 60rem: hotpink, <color>);
  line-height: map(var(--scale), 20rem: 1.2, 60rem: 1, <length>);
}

[tabatkins]

@bramus

Naming the functions value-mix() and value-map() feels more natural to me, as you are mixing and mapping values.

When "value" is used in CSS, it refers to a much more generic concept, akin to what the generic map() function operates on. It's definitely not used as a specific term for numeric values, in general.

So if colors get mixed with color-mix(), then (untyped) values gets mixed with … value-mix(), no?

Hm, now I'm confused why you are connecting this to the calc-mix()/calc-map() functions. calc-mix/map() are about mixing/mapping numeric values, not generic values.

[tabatkins]

@ydaniv

Just not sure I understood the each part. IIUC by is for easing the entire range, and each for easing per breakpoint? Kind of like animation-easing and animation-timing-function?

Exactly correct.

[tabatkins]

@scottkellum

I’m curious if there are any ways to use map() everywhere and either pass in the unit type or infer it.

Can't infer the type; many values are ambiguous. The problem with passing in the type is that there are often type-specific controls you want (like in color-mix()), so we'll want specific functions anyway. The exact type also has some implications about the general grammar, like calc-mix() has to fix the order of the value and the %, while color-mix() can allow them in any order.

(Note as well that in your example, the line-height values are not lengths, they're just numbers. Exact CSS type can sometimes be a bit confusing in properties.)

[LeaVerou]

This seems very related to this issue I opened last month: #11530

I’m still digesting @tabatkins' proposal in #6245 (comment) so apologies if I’ve missed something.

While not a strong objection, I’m not crazy about the idea of introducing even more functions. I don't see a strong disambiguation reason to do so (color stop positions can just always come after the value), and it makes the language harder for authors. Much easier to find what they are looking for when there is a 1-1 mapping of functions to purposes (it's already suboptimal that we need to have multiple functions for each interpolated type, but I understand the reasons for this…). Conceptually, "I want to interpolate between A and B" is not that different from "I want to interpolate between A, B, and C" to warrant a whole different function.

I do agree that mixing and interpolation do seem like fundamentally different concepts. However, do we actually need mixing versions for other types of values? For color, mixing has an established meaning in the physical world, but I don't think anyone thinks about mixing <length> or <number> units. What does that even mean? And I’m not even sure the concept makes sense for images, at least any more than interpolation. We generally don't add nontrivial features for completeness' sake, so if there are no use cases for mixing anything other than colors, then we shouldn't have these.

I’m more strongly opposed to the *-map() naming. Maps have an established meaning in both programming languages and CSS preprocessors: they help you transform one (often categorical) value into another, e.g. so one can do things like transform vertical into column and horizontal into row. There have been several requests to add mapping functions to CSS (#7273 came up from a quick search, but pretty sure there have been many more). While something like calc-map() doesn't preclude something like map() or map-get() or whatever from being added, it does mean that now the same terminology is used for two distinct concepts. But even if we never add mapping functions, the concept still exists so having a *-map() function that doesn't work like a map is very confusing.

So if we don't name them *-map() what do we name them? The obvious choice is something around interpolation (e.g. calc-interpolate()) though that is both exceedingly long and overly technical (violating TAG principle 12.1: Use common words).

Name	Common word?	Short?	Clear? (to those who know the word)
*-interpolate()	❌	❌	✅
*-tween()	❌	✅	✅
*-range()	✅	✅	❌ Sounds like it returns a range, rather than a value
*-intermediate()	✅	❌	✅
*-scale()	✅	✅	✅

Yup, the more I think about it, the more it seems to me that *-scale() ticks all the boxes. color-scale() is particularly fitting, but calc-scale() doesn't seem bad either. image-scale() is a bit weird (looks like it's scaling an image) but oh well.
In fact, I think it's a sufficiently good name that I withdraw my (very weak) objection above about having multiple functions. 😁

[css-meeting-bot]

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

The full IRC log of that discussion

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

[fantasai]

Syntax follow-up questions are:

• What should be the name of the function? (We're going with -scale for now, but open to other ideas.)
• What should be the separators a) between stops b) between stop input value and stop output value?
• Is by vs each reasonable or do we have other ideas for disambiguating the easing function applied to the progress as a whole vs between stops?

[scottkellum]

For me, scale is too similar to the transform: scale() function, and I immediately think of scaling in geometry. For this reason, it feels unclear to me. I agree with Lea on map.

Other options that I’ll throw in:

• *-change
• *-morph

I like morph the best, but will leave it to all the smart folks here to debate some more.

[benface]

*-interpolate makes the most sense to me.

[bramus]

(#) For me, scale is too similar to the transform: scale() function, and I immediately think of scaling in geometry.

+1

(#) *-interpolate makes the most sense to me.

Also +1. The word might be long, but it most accurately reflects what is happening.

I would also argue against interpolate not being a common word. A lot of specs use the term and it’s also used in developer facing documentation such as linear() on MDN

[tabatkins]

We use a lot of technical terms in the specs that don't translate to author-facing names. interpolate is, imo, on the edge of too complex to show up in an API name.

Is by vs each reasonable or do we have other ideas for disambiguating the easing function applied to the progress as a whole vs between stops?

Could be more explicit, like ease-input vs ease-each

[LeaVerou]

If *-scale() is out of the question, I would also go for *-interpolate() despite its shortcomings. As @bramus pointed out, it is used extensively in docs, as well as userland libraries (e.g. https://d3js.org/d3-interpolate ). Things like morph seem incredibly confusing to me.

WRT each, do we have enough use cases to warrant figuring this out now? It seems to me that this can be retrofitted later.

This also reminds me, can these be nested? How does that behave? (also not for the MVP)

[mirisuzanne]

ease-all and ease-steps?

Re *-scale - In theatrical lighting design we would call this a sequence or a chase. I think sequence translates here decently. In CSS we already call the same concept a set of keyframes. Is there a way to re-use that terminology? These are really just inline keyframes, right?

[tabatkins]

Hmmmm I was gonna complain that I didn't like using that for the generic function because it can take a keyframes name as an argument, but actually keyframes(media-value(width) my-kf-rule) looks pretty decent.

And that lets us link the concept super directly to that of easing between keyframes vs over the whole animation, etc.

[tabatkins]

This also reminds me, can these be nested? How does that behave? (also not for the MVP)

Yeah, it Just Works, since they resolve to an appropriately typed value. (Including the generic one, as its arguments are <whole-value>, which the generic one matches.) None of this is based on any implicit state, it's a fully self-contained calculation, so there's no issues with nesting besides the obvious unreadability.

[bramus]

(#) interpolate is […] too complex to show up in an API name.

There is precedent:

• SVG and CSS: color-interpolation
• color-mix()’s <color-interpolation-method>
• <hue-interpolation-method> in gradients
• interpolate-size

[tabatkins]

The second and third aren't part of the "author-facing API", they're just spec terms.

The first and fourth, granted.