W3C home > Mailing lists > Public > www-style@w3.org > November 2012

Re: [css4-images] One color stop should now be allowed

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 5 Nov 2012 15:33:21 -0800
Message-ID: <CAAWBYDC8D+USRPjx3uEVn7p9KTqJTGdFnTOiVjJTpL1pxwRGTg@mail.gmail.com>
To: Lea Verou <lea@w3.org>
Cc: www-style list <www-style@w3.org>
On Mon, Nov 5, 2012 at 11:05 AM, Lea Verou <lea@w3.org> wrote:
> Since we can now have two positions per color stop [1], which is equivalent
> to two color stops with the older syntax, gradients should permit one color
> stop only. Grammar-wise, it's only a matter of converting a few +s to *s.
> In case the only color stop doesn't include two positions, it could be
> defined as equivalent to having 0% 100%. Yes, this is essentially identical
> to using image(color), but:
> 1. There is no serious reason to disallow degenerate applications of any CSS
> feature and few other CSS features do.
> 2. It ensures consistency and matches author expectations.
> 3. Good educational value: People who use editors that live update will be
> able to see what they're doing before they even type the second color.
> Instant feedback is an age-old UI principle and syntax is the UI of the
> language.
> 4. It's trivial to implement.
> [1]: http://www.w3.org/TR/css4-images/#color-stop-syntax

While I don't have anything particularly *against* such a thing (as
you point out, it's trivial to handle), is there any good reason to do
it?  A gradient with a single color isn't a gradient at all.

Why do you think it matches author expectations to allow a single
color?  ("Because they told me so" is fine, though I'd like more
detail about what confused them.)

Allowing live editors to provide feedback as soon as possible is a
decent reason (part of why CSS allows so much to be omitted in the
first place), but before you add the second color, you don't even know
what the gradient *looks* like.

I imagine that if there was only a single color-stop, it would just
compute itself to "color 0% 100%"?

Received on Monday, 5 November 2012 23:34:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:23 UTC