New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-images] Add easing functions to color stops #1332

Open
meyerweb opened this Issue May 8, 2017 · 33 comments

Comments

Projects
None yet
8 participants
@meyerweb

meyerweb commented May 8, 2017

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

This comment has been minimized.

meyerweb commented May 8, 2017

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

This comment has been minimized.

AmeliaBR commented May 8, 2017

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

This comment has been minimized.

Contributor

svgeesus commented May 8, 2017

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

This comment has been minimized.

larsenwork commented May 8, 2017

@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

This comment has been minimized.

meyerweb commented May 8, 2017

@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

This comment has been minimized.

AmeliaBR commented May 8, 2017

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

This comment has been minimized.

larsenwork commented May 8, 2017

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

This comment has been minimized.

meyerweb commented May 8, 2017

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

This comment has been minimized.

AmeliaBR commented May 8, 2017

@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

This comment has been minimized.

larsenwork commented May 9, 2017

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

This comment has been minimized.

meyerweb commented May 9, 2017

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

This comment has been minimized.

larsenwork commented May 9, 2017

@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

This comment has been minimized.

AmeliaBR commented May 9, 2017

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:

An XY graph with a range of 0 to 1 on both axis. Three lines on the graph: a straight x=y line, a concave curve, and a convex curve.  Points at x=0.5 on each curve are connected, labelled by the y-values: 0.73, 0.5, and 0.218 for each.

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

This comment has been minimized.

AmeliaBR commented May 9, 2017

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.

@meyerweb

This comment has been minimized.

meyerweb commented May 9, 2017

Ah! Given that, I agree, putting the interpolation function into the same spot as the hints (as a separate comma-separated value) makes the most sense. To authors, it will feel like “here’s this new interstitial thing that gives me a lot of easing options” and that’s perfect. It also makes hard-stop gradients a lot easier to create, simply by putting in a step rather than having to string together a whole series of color pairs with stop distances that touch adjacent pairs.

Would there be utility in allowing both a <length-percentage> and an interpolation function, as a way of modifying the shape of the interpolation? Or too many curves being smooshed together that way?

@AmeliaBR

This comment has been minimized.

AmeliaBR commented May 9, 2017

Would there be utility in allowing both a and an interpolation function, as a way of modifying the shape of the interpolation? Or too many curves being smooshed together that way?

How are you imagining that would work? I think the math would get pretty hairy.

Authors can always break the gradient down into multiple stops if they really want more control.

@meyerweb

This comment has been minimized.

meyerweb commented May 10, 2017

I have no idea how that would work, to be honest. I brought it up mostly to see if the smarter and more math-oriented people on the thread (read: everyone) thought it would be useful.

@larsenwork

This comment has been minimized.

larsenwork commented May 10, 2017

If the goal is modifiable interpolations then instead of length-percentage together with interpolation function I'd vote for ability to use cubic-bezier and not just ease, ease-in, linear etc. — or that was maybe already the idea?

so something like:

linear-gradient(black, cubic-bezier(0.470, 0.000, 0.745, 0.715), white)

Not sure how that would work for numbers > 1 though.

@AmeliaBR

This comment has been minimized.

AmeliaBR commented May 10, 2017

@larsenwork

If the syntax referenced the timing-function/transition function data type, then a cubic-bezier() function would automatically be included, as an alternative to the shorthand keywords.

@tabatkins

This comment has been minimized.

Member

tabatkins commented May 10, 2017

If we added this, it would indeed extend the <linear-color-hint> grammar, so @larsenwork's example syntax (the timing function on its own, comma-separated from the two surrounding color-stops) is indeed how it would look.

This proposal overall sound interesting and is definitely potentially doable, but I'd like to see how far people can take just the mid-point approach first. None of the blogposts talking about smoothing gradients seem to acknowledge their existence (which is understandable, given that they're embedded deep in Images 4 right now). They should help things quite a bit.

@larsenwork

This comment has been minimized.

larsenwork commented May 10, 2017

@tabatkins I will try to do a proper stress test of the hint approach to see what it can render but I'm not too confident in what it will yield as the critical part of easing a gradient is having something with a terminal and/or final "velocity" of 0 which doesn't seem doable with hints. But I'll give it a go and also update the plugin with the proposed syntax here to see an approximation of what you could do if this syntax was supported

@tabatkins

This comment has been minimized.

Member

tabatkins commented May 10, 2017

My concern is just whether the midpoint approach can give a decent-looking "soft fade", not whether it can reproduce any particular mathematical definition. It appears to be good enough for Photoshop, so I'm curious to see example of it not being good enough for CSS.

@larsenwork

This comment has been minimized.

larsenwork commented May 12, 2017

I've quickly updated the playground to support the syntax proposed by @AmeliaBR e.g.

linear-gradient(black, cubic-bezier(0.48, 0.30, 0.64, 1.00), transparent)

NB - the plugin has some limits for now:

  • hacks by creating many color stops and as such might have some artefacts.
  • only supports cubic-bezier(), ease, ease-in, ease-out, ease-in-out but adding steps() should be fairly trivial.
  • doesn't yet support color-stop-positions but should also be easy to add.

http://codepen.io/larsenwork/pen/WjJorb?editors=0100

@tabatkins I haven't been able to easily recreate the curve in the example with hints (but again I'm not too familiar with the approach).
Basically I wanted a gradient that faded out nicely but also had a modified s-shape to avoid being too dark in top. Creating an asymmetrical s-shape like that with cubic-bezier() is much more intuitive than trying to balance out three color-stops with two hints even if it's possible to get something visually similar that way (I wasn't). I've never been satisfied with the gradient options in Photoshop and know designers who either stack gradients, use gaussian blur or other "hacks" to create visually pleasing gradients.

@bradkemper

This comment has been minimized.

bradkemper commented May 13, 2017

Do we need the timing function for each stop, or could there just be one that applied to the entire gradient? Intermediate stops would just get interpolated.

@larsenwork

This comment has been minimized.

larsenwork commented May 13, 2017

Created another demo. This one doesn't show why we'd want this compared to hints in terms of "soft-fades" (see the previous one for that) but I've added support for steps() which I also find quite useful. https://codepen.io/larsenwork/pen/LymMJy/?editors=0100

EDIT: Removed sidenote about steps — see #1371

@AmeliaBR

This comment has been minimized.

AmeliaBR commented May 13, 2017

@larsenwork

Symmetrical step functions are currently being called frames(). But that is being debated in #1301 .

Your fourth example matches frames(4): four equally-allocated values, including both the start and end values. Your third example doesn't match any existing timing function.

@larsenwork

This comment has been minimized.

larsenwork commented May 14, 2017

@AmeliaBR cheers, I'll crop it out of this discussion to keep it on track then :)
@bradkemper we want to add it between stops — see #1332 (comment) and #1332 (comment) for details. Maybe @meyerweb can update the first comment so that newcomers can quickly see what the request is :)

@meyerweb

This comment has been minimized.

meyerweb commented May 16, 2017

@bradkemper: I can envision wanting a single easing over an entire gradient of un-positioned stops, like red, orange, yellow, green, blue, purple, ease-out but I don’t see how that can be done while also allowing for different easings between the various stops, like red, ease-out, orange, ease-in, yellow, linear, green….

@tabatkins

This comment has been minimized.

Member

tabatkins commented May 16, 2017

"Single timing function crossing all the stops" is not how animations work right now; when you supply an animation-timing-function, it just sets the default for all the keyframes' individual timing functions.

If you don't supply a hint between two stops (midpoint or timing-function), you'll just get a linear transition like you do today.

@birtles

This comment has been minimized.

Contributor

birtles commented May 16, 2017

Note that Web Animations lets you apply a single timing function crossing all the stops (keyframes) as well as timing functions between stops (keyframes). It's a very commonly requested feature so I suspect we'll end up adding some sort of "overall" timing function to CSS Animations Level 2 as well.

@bradkemper

This comment has been minimized.

bradkemper commented Jun 10, 2017

OK, yeah, I was thinking of simpler gradations, but I can certainly see the need for easing in and out in different parts of the same one.

@larsenwork

This comment has been minimized.

larsenwork commented Jan 30, 2018

FWIW I've created an easing-gradient editor https://larsenwork.com/easing-gradients/#editor so people can play around with it to see the possibilities/flexibility easing functions provides.

The end result has some banding because that's how I can currently fake it but I'd imagine native browser support resulting in silky smooth gradients.

I'll add steps() functionality to the editor soon too — probably with a syntax like this #1680 (comment) for now.

@Juribiyan

This comment has been minimized.

Juribiyan commented Mar 16, 2018

Seems like a good case to implement this with Houdini

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment