[css-easing] The `midpoint` easing function

[danburzo]

Insofar as easing functions make it into the CSS gradient syntax, I would like to propose a new easing function, tentatively called midpoint(x), for smooth interpolation between color stops, without the drawbacks of the interpolation hints syntax.

1. In the css-images-4 spec, interpolation hints seem to affect how color stops are positioned, and at least current browser interpretations adhere to that reading of the spec.
2. The proposal to add easing functions to gradients (in particular, the syntax analogous to adding hints between color stops) promises to disentangle the interpolation functions from color stop position computations.

To enable authors to obtain an intuitive effect from interpolation hints without the drawbacks outlined in (1) and without retroactively redefining the behavior of interpolation hints, we can piggy-back on the easings proposal (2) to present authors with similar functionality.

The midpoint easing function takes a single argument x ∈ [0, 1] that controls the relative position of the midpoint between the two color stops A and B. The resulting color is computed (by following the interpolation hint definition) as follows:

1. if x = 0, return color B for any point between the two color stops (equivalent to step-start)
2. if x = 1, return color A for any point between the two color stops (equivalent to step-end)
3. if x ∈ (0, 1):
   1. compute the position t ∈ [0, 1] of the point, relative to the two color stops
   2. obtain the weighting between color stops C = t^log_x(.5)
   3. the color at the point is then a linear blend between the colors of the two color stops, blending (1 - C) of the first stop and C of the second stop.
4. the particular case x = 0.5 is equivalent to linear

These two definitions are equivalent:

linear-gradient: (to right, red, 25%, green);
linear-gradient: (to right, red, midpoint(0.25), green);

I have opted for x ∈ [0, 1] instead of x ∈ [0%, 100%] to make it clear that the value is local to the easing function, and not a position along the gradient line.

[AmeliaBR]

In general, I like the idea of defining an easing function equivalent to the curve created by color hints. It would be convenient when defining animations and transitions, for the same reasons that it is simple and intuitive in gradients.

For reference, an easing function defined as midpoint(H) for some H value <number [0,1]> would define a curve represented by the following y=f(x) calculation in JS syntax:

exp = Math.log(0.5)/Math.log(H);
y = Math.pow(x, exp);

y would always equal 0.5 when x equals H.

I'm not sure about the name midpoint, but I don't have a better proposal at this time.

I like the idea of restricting the parameters to abstract values between 0 and 1 to avoid confusion with percentage lengths in gradients or percentage time selectors in animation keyframes. And it's consistent with the cubic-bezier() easing function.

The complication with the fix-up algorithm is unfortunate, but I like your solution of restricting that interaction to the current color hint syntax, so that in general easing functions could be added to gradients in future without affecting positions.

[cabanier]

Interpolation hints are regular color stops. I'm unsure why you say that they "affect color stop positioning". Are authors complaining about the positioning algorithm?

Why would you add easing functions to gradients? Doing cubics will cause artifacts and afaik no other graphics format defines gradients that way.

[danburzo]

What I mean that, reading the spec and trying to implement the color stop positioning algorithm outlined in it — with my understanding on it, and lacking other context to its history — I was surprised to find current browsers have a different approach. (Hence my question in #3931).

Are authors complaining about the positioning algorithm?

I'm not aware of anything of the sort. I chanced upon it writing some test cases for an implementation I'm working on. Might be an edge-case to mix unpositioned color stops with interpolation hints in the same gradient and, even then, seeing that browsers render it consistently, as an author you might be inclined to accept it as-is. (As such, I think the resolution to pave the cowpaths in this regard is appropriate.)

This proposal (a midpoint easing function) was a thought (or compromise, if you will) to align what I think is the spirit behind interpolation hints in a way that does not affect how browsers currently implement them. That being said, it's a proposal that's dependent on, and a supplement to, easing functions in gradients — for which the rationale is being tracked in #1332.