[css-images-4] Gradients with a single color stop

[LeaVerou]

Gradients with a single color stop were supposed to be allowed in CSS Images 3, but due to a bunch of issues and a grammar that was mismatched to the prose, they didn't make it to implementations.

Since there are no implementations, @fantasai and I decided to remove any references to single color gradients in Images 3. This issue is about getting WG consensus to add this in Images 4.
Use cases: Better feedback while writing CSS with a preview, single color images, "placeholder" gradients that are going to be edited later. But mostly, consistency and predictability.

[bradkemper]

I'm all for defining things that are undefined, but if no implementations are doing that already, don't we risk messing up existing Web page that might have experimented with single color gradients and then left them there and forgot about them?

Is there any advantage to linear-gradient(red) over image(red)?

[css-meeting-bot]

The CSS Working Group just discussed [css-images-4] Gradients with a single color stop.

The full IRC log of that discussion

<astearns> topic: [css-images-4] Gradients with a single color stop
<astearns> github issue: https://github.com//issues/1576
<fantasai> leaverou: Intended to be allowed in images 3, was prose in the spec...
<fantasai> fantasai: Actually, no, the CR of gradients did not include it in prose or grammar
<fantasai> leaverou: But anyway, would like to relax in Images 4
<fantasai> leaverou: Doesn't allow a lot of use cases, but it's simple case and improves debugging / preview
<fantasai> leaverou: Can quickly see the gradient
<fantasai> leaverou: Use case of single color image isn't great, because we have image() function for that
<fantasai> leaverou: I'm fine either way
<fantasai> leaverou: But would allow it if it was up to me
<fantasai> leaverou: Thoughts?
<dbaron> seems reasonable to me if there aren't compatibility issues -- and if implementations can update in a reasonably synchronized way
<fantasai> Florian: Since it's a syntax you could easily accidentally write, hoping for it to do somehting, even though it currently does not, there's a non-trivial risk of web pages out there relying on it not working
<fantasai> Florian: Maybe not, but could be a case
<fantasai> leaverou: Could we get stats?
<fantasai> ChrisL: People wanted to do solid colors and animate ...
<fantasai> ChrisL: There were people who wanted to have a single color gradient
<fantasai> leaverou: We have image(<color>)
<fantasai> ChrisL: Which way should we move people , towards image() or linear-gradient()?
<fantasai> TabAtkins: Would prefer to move ppl to image(), much clearer and shorter
<fantasai> ChrisL: It's also unintuitive to get that effect.
<fantasai> Florian: If you use it as a start point for an animation, though, then linear(blue, blue) ...
<fantasai> TabAtkins: For animations, you need to match up number of stops anyway
<fantasai> leaverou: So the main use case seems to be debugging / tooling
<Florian> s/.../ is easily written/
<fantasai> astearns: We are over time, not hearing any implementers lining up for this
<fantasai> astearns: Maybe solicit feedback directly from implementers, if anyone wants to champion then add back to agenda
<fantasai> astearns: If not, shouldn't go in spec
<fantasai> astearns: Thanks everyone, we're done.
<fantasai> Meeting closed.

[SebastianZ]

To me it sounds like single-color gradients were only a workaround for the missing possibility to define single-color images. With image(<color>) there's a way to do that now.

Regarding the feedback while writing the gradients sounds plausible. Though a color gradient consists of two or more colors by definition. And I fear that if this is introduced, authors may use this one instead of the intended image(<color>) function just because they don't know it better or because implementers add the single-color gradient before the image() function.

Sebastian

[LeaVerou]

Regarding the feedback while writing the gradients sounds plausible.

Think of authoring environments like dabblet, codepen, jsfiddle etc, where it's common to have a the result update while typing or browser plugins like LiveReload. Currently one needs to type a lot to see a result with gradients and start fiddling with the colors to get them right.

Though a color gradient consists of two or more colors by definition.

It also consists of, you know, actual gradation, and yet we support degenerate gradients which consist of 2 solid colors with no gradation between them.

And I fear that if this is introduced, authors may use this one instead of the intended image(<color>) function just because they don't know it better or because implementers add the single-color gradient before the image() function.

And the problem with that is…? If it gives them functionality they need without having to learn more things, I'd say that's a win. If it gives them a feature they need earlier than they might otherwise get it, that's an even bigger win.

[SebastianZ]

Regarding the feedback while writing the gradients sounds plausible.

Think of authoring environments like dabblet, codepen, jsfiddle etc, where it's common to have a the result update while typing or browser plugins like LiveReload. Currently one needs to type a lot to see a result with gradients and start fiddling with the colors to get them right.

That means to me that the tools need to be improved to provide some autocompletion.

Also, allowing single-color gradients doesn't really save you much, you still have to write a second color to get a proper gradient. You'd just see the first color a little bit earlier.

And I fear that if this is introduced, authors may use this one instead of the intended image() function just because they don't know it better or because implementers add the single-color gradient before the image() function.

And the problem with that is…?

That the semantic between a single-stop gradient is different, so the function will be abused to create color images.

Sebastian

[LeaVerou]

That means to me that the tools need to be improved to provide some autocompletion.

Autocompletion doesn't replace early feedback (a tenet of good usability) and too much of it can often be annoying as it's prediction instead of feedback, and predictions can be wrong.

Also, allowing single-color gradients doesn't really save you much, you still have to write a second color to get a proper gradient. You'd just see the first color a little bit earlier.

Yes, and that's super valuable: You can tweak that color, you can make sure the rest of your syntax is valid (background declarations can get pretty complex), it's a smoother process overall.

That the semantic between a single-stop gradient is different, so the function will be abused to create color images.

Abused how? Without any tangible danger, it sounds more like a knee jerk reaction than a rational argument to me. Reminds me of those complaints about authors doing stripes with gradients, which cited vague dangers that sounded a lot like "it's not proper dammit". Eventually we even added syntax to make it easier.

[tabatkins]

Yeah, there's nothing wrong with single-stop gradients; it's just a matter of whether it's worthwhile making the change to the spec and to implementations, given that you can already achieve the same effect (with two stops, or with the image(<color>) function when browsers support that). As concluded in the call, we're holding off on this until a browser vendor actually expresses interest in it.

[svgeesus]

Looks like this old issue got overtaken by events. 3.5.1. Color Stop Lists says

Color stops and transition hints are specified in a color stop list, which is a list of one or more color stops interleaved with optional transition hints:

(notice the one or more)

The actual discussion and resolution happend in

• [css-images-4] Allow gradients with a single color stop and 0-1 positions #10092