Open LeaVerou opened 7 years ago
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)
?
The CSS Working Group just discussed [css-images-4] Gradients with a single color stop
.
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
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 theimage()
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.
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
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.
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.
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.