[css-images] Add easing functions to color stops

[meyerweb]

A recent CSS-Tricks article (https://css-tricks.com/easing-linear-gradients/) and subsequent Twitter discussion (https://twitter.com/stubbornella/status/861603397677359104) spurred me to file this request for Level 4.

In summary, linear gradients are not always visually acceptable. This is particularly true when “fading out” a dark color to transparent. The article describes how to set up a bunch of color stops to ease out the gradient. A much better solution would be to add easing functions to all color stops after the first, with a linear default for backward compatibility.

The example in the article could be approximated like this:

linear-gradient(to bottom, black 0%, transparent 100% ease-in-out);

…instead of the 11 color stops used to get the effect. (Note that I don’t claim this would be a precise match; a cubic-bezier() easing would most likely be required for that. But it would be close.)

This would change the definition of <color-stop> (https://drafts.csswg.org/css-images-3/#typedef-color-stop) from:

<color-stop> = <color> <length-percentage>?

…to the following at a minimum:

<color-stop> = <color> <length-percentage>? <timing-function>?

As an author, I would probably prefer:

<color-stop> = <color> [ <length-percentage> || <timing-function> ]?

…since that would allow me to write the easing and distance in whichever order I liked. (For that matter, I’d prefer to be able to write all three in any order, but I don’t know if that would upset any implementors’ apple carts.)

[meyerweb]

Apologies for forgetting this at initial filing: <timing-function> would use the same values as transition-timing-function, with the same definitions. (https://www.w3.org/TR/css3-transitions/#transition-timing-function-property)

[AmeliaBR]

I really like this syntax. I've long had an idea of proposing easing for SVG gradients by borrowing the SMIL keySplines attribute. But of course, named CSS easing functions are much nicer.

However, we would need to figure out how it interacted with the gamma curves created by color hints, since those are already implemented & will be moved up to CSS Images Level 3.

[svgeesus]

However, we would need to figure out how it interacted with the gamma curves created by color hints, since those are already implemented & will be moved up to CSS Images Level 3.

Good point, see #1284 which adds a 'midpoint' - somewhat oddly named, it turns the linear interpolation between adjacent color stops into a curve, effectively moving the point at which the midway color is reached to be earlier (curve up) or later (curve down). This is way easier to understand with a diagram, of course. (an interactive diagram would be even better).

Being defined by a single point, it is less flexible than easing functions which are defined by two points, giving S-shaped curves as well..

[larsenwork]

@meyerweb My attempt was mostly a proof of concept and as such nowhere near flexible enough so thank you very much for picking up my idea and making it way better 👍
I'm curious how the <color-stop> = <color> [ <length-percentage> || <timing-function> ]? would work in practice since timing functions refers to the transition between two stops.

Should one only be able to add timing-function to subsequent stops so it always describes how the gradient transitions from the previous stop to the stop with the timing-function applied?

Or would

linear-gradient(black 0%, transparent 100% ease-in-out);

effectively be the same as

linear-gradient(black 0% ease-in-out, transparent 100%);

and if so, then how should

linear-gradient(black 0% ease-in-out, transparent 100% ease-in);

be interpreted?

[meyerweb]

@larsenwork: My thought was that the timing function (really an easing function) for a color stop described the easing from the previous stop to itself, so an easing function on the first color stop would be ignored (though not invalid).

Thus:

linear-gradient(black 0%, transparent 100% ease-in-out);

…describes an ease-in-out from the previous color stop (black) to the current color stop (transparent). Therefore, your second example:

linear-gradient(black 0% ease-in-out, transparent 100%);

…is actually equivalent to:

linear-gradient(black 0% ease-in-out, transparent 100% linear);

If the <color> [ <length-percentage> || <timing-function> ]? syntax were adopted, then this would also be equivalent:

linear-gradient(black 0% ease-in-out, transparent linear 100%);

…because the easing function and distances could be written in any order.

[AmeliaBR]

To address @larsenwork's question, and also to synchronize with the mid-points syntax, maybe the easing function should be a separate item in the list. You would either use a or a mid-point position

So, working from the value definition in CSS Images 4 the full syntax for a <color-stop-list> would be:

<color-stop-list> =
  [ <linear-color-stop> [, <linear-color-hint>]? ]# , <linear-color-stop>
<linear-color-stop> = <color> && <color-stop-length>
<linear-color-hint> = [<length-percentage> | <animation-timing-function>]
<color-stop-length> = <length-percentage>{0,2}

In English:
A color stop list is a comma-separated list of two or more color stops.

Each color stop consists of a color value and an optional position value, or start and end positions values.

Each pair of consecutive color stops may optionally be separated by an interpolation instruction, which is also set off by commas. The interpolation instruction may take one of two forms:

• a mid-point position, which is defined in the same way as a color stop position, or
• an interpolation function, which is identical to the timing functions defined in CSS Timing Functions 1.

---

PS, If this goes ahead, CSS Timing Functions 1 should probably be changed to CSS Interpolation Functions or some other dimension-agnostic name.

[larsenwork]

so an easing function on the first color stop would be ignored (though not invalid)

Just out of curiosity then why no make it invalid on the first color stop?

I'm also not sure what would be gained by making the order of easing and distance flexible. I think it could end up making the gradient function harder to read so I'd vote for

<color-stop> = <color> <length-percentage>? <timing-function>?

but I think you @AmeliaBR make some really interesting points too. Just to understand the syntax you're proposing it would be something like

linear-gradient(black, ease-in-out, white)

right?

Which would make intuitively sense since the transition-functions (as I'd agnostically call them) describes how to transition between to stops.

[meyerweb]

Just out of curiosity then why no make it invalid on the first color stop?

Because I don’t want to have the entire gradient fail to render just because someone left an easing function in when they deleted the first stop during authoring. Also it makes defining the value syntax easier, since there can just be <color-stop> instead of <first-color-stop> and <color-stop>.

[AmeliaBR]

@larsenwork

Just to understand the syntax you're proposing it would be something like linear-gradient(black, ease-in-out, white) right?

Right! Sorry, I should have actually included some examples.

It's not a perfect syntax, because it means the entries in the comma-separated list aren't all equal, but it's consistent with the existing mid-point color hint syntax.

[larsenwork]

Having slept on it I'm leaning towards @AmeliaBR approach. To sum up:

Pros

• Consistent with current <linear-color-hint> syntax
• Has the logical limitation that easing can only be applied between color-stops

Cons

• The comma separated values aren't created equal but was already the case with hints

[meyerweb]

What are color interpolation hints meant to be now? I can’t seem to find any examples, and the definition (https://drafts.csswg.org/css-images-4/#color-interpolation-hint) doesn’t make it at all clear what’s meant. Is it basically what this issue is about, or something else?

[larsenwork]

@meyerweb the color hints only shifts the halfway point and effectively creates two linear gradients in the process — at least that's what I'm gathering from the description and examples on csswg where e.g.

linear-gradient(rgb(100%, 0%, 0%), 25%, rgb(100%, 100%, 100%))
renders like
linear-gradient(rgb(100%, 0%, 0%) 0%, rgb(100%,50%,50%) 25%, rgb(100%, 100%, 100%) 100%)

and as such of fairly limited use when wanting to create smooth gradients but maybe @AmeliaBR could clarify.

EDIT: no, I was incorrect. It does some smoothing. It's still not quite there visually compared to proper ease-functions.

EDIT 2: made a quick comparison of the output here: https://codepen.io/larsenwork/pen/pPpMpb/

[AmeliaBR]

Yes, the color hint creates a curve. I'd really like to see better figures in the spec, but it uses the same math as a gamma correction curve like this one:

That graph is showing paired encoding and decoding gamma curves for luminance adjustment, which isn't relevant to this discussion.

But the shape of the curves is. One axis would be the distance along the gradient and the other axis is the distance in color-space. Normally, for an easing function the Y axis would be the color value, but for re-interpretting this graph as it's currently labelled, it's easier if you treat the X axis as the color value and the Y axis as the distance. A midpoint color hint of 73% says to use the curve where 50% in color-space is positioned at 73% in the gradient distance. A color hint of 21% says to use the curve where the mid-point color is positioned at 21% distance.

(And of course, a mid-point of 50% means the mid-point color gets positioned at the 50% distance, so it's equivalent to simple linear interpolation.)

[AmeliaBR]

But to answer @meyerweb's question

Is it basically what this issue is about, or something else?

The color hints were one way to address the problems with linear gradients being ugly in many cases. They are based on gradients used in Adobe products. The mid-point position is easy to represent and intuitive to adjust in a visual editor.

But as @svgeesus noted, the curves created by mid-point adjustments are less flexible than the cubic bezier curves used in the transition functions, because they are defined by one point, not two. In particular, you can't create an S-curve, ease-in-out relationship. And you definitely cannot create steps. So I think there is a value in having both: the mid-points for their simplicity, and full transition functions for more control.