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

Re: [css3-images] Proposed Gradients changes

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 30 Nov 2010 11:35:17 -0800
Message-ID: <AANLkTi=__XtmxijiJWmPPDMBq91jN9NNN_UcQzBo+QQf@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: Rik Cabanier <cabanier@adobe.com>, www-style list <www-style@w3.org>
On Mon, Nov 29, 2010 at 6:12 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
> On Nov 29, 2010, at 5:06 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
> There is not a huge difference in typing "-50% -50% 200% 200%" instead of "top left". Sure, it's a few more keystrokes, for a somewhat less common need. But I think it is worse to have duplicated functionality inside the image, creating multiple ways to do the same thing, with very little gain.

I'd agree if gradients in general, and these abilities in specific,
were *only* useful in background images.  As I've explained before, I
don't think this is true.

> Maybe if it was only edge names and 'center' to add to the syntax it wouldn't be that bad (and similar to linear-gradient). But there are all these other bits and bobs too (cover, contain, closest-corner, closest-side, farthest-corner, farthest-side, circle, ellipse, explicit lengths and percentages), that also must be learned and are also mostly redundant, which turn a very simple thing into a collection of unneeded complexities. No offense, but I'd call it over-engineered.

Of these, I agree that closest-corner and farthest-side aren't
strictly necessary.  They basically come along for free with cover and
contain, which are farthest-corner and closest-side, respectively.

cover and contain themselves are quite necessary, unless you actually
think that it's easier to tell people "the final color stop needs to
be at 141% to make the gradient fully cover the box" (I think this is
only true for gradients that are centered in the box, centered on a
side, or on a corner, actually).  That's a *completely irrelevant*
algebraic detail for nearly everyone, so papering it over with a
keyword is a big win.

Similarly, some ability to control the eccentricity of the ellipse
seems necessary, and the circle/ellipse distinction seems to be the
minimum necessary.

Finally, given the above, explicit lengths and percentages are
required for interpolation purposes.  While ordinary authors *can* use
them, they're not expected to.  There's no way around this.

There were parts that were over-engineered, imo, such as the <angle>
in the first argument to radial-gradient, for example, which I've now
dropped.  I've also had a lot of other ideas for gradients that I've
rejected because I felt they were adding complexity without a
sufficient win in addressing use-cases.  I think that what we're left
with now is clear, simple, and widely useful.  You're free to

Received on Tuesday, 30 November 2010 19:36:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:41 UTC