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

Re: radial-gradient() proposal

From: Brendan Kenny <bckenny@gmail.com>
Date: Fri, 6 Nov 2009 16:57:57 -0600
Message-ID: <ab96c3ef0911061457g5620b689q811c8330b44908eb@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, Brad Kemper <brad.kemper@gmail.com>, Simon Fraser <smfr@me.com>, www-style list <www-style@w3.org>
On Fri, Nov 6, 2009 at 2:13 PM, Brendan Kenny <bckenny@gmail.com> wrote:
> On Fri, Nov 6, 2009 at 1:55 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Fri, Nov 6, 2009 at 11:34 AM, Brendan Kenny <bckenny@gmail.com> wrote:
>>> 1. An angle, a start point and a length
>>> or
>>> 2. An angle, which forms an assumed axis covering the entire box and
>>> color stops (including beginning and end) as lengths along that axis.
>>> Without lengths it could be assumed we start at 0% and end at 100%.
>>>
>>> I'm torn on which seems better. (1) would give an author more obvious
>>> control (without having to do any napkin calculations to find
>>> percentages they want)
>>
>> I'm okay with requiring basic napkin calculation to handle the case of
>> knowing what %s you want the stops to be at *and* knowing what length
>> you want the entire gradient to be.  That's a trivial enough
>> calculation (I want a 25% stop in a 260px gradient, so 260 * .25 =
>> 65px) that I don't think it's a problem we need to solve.  It's when
>> an author has to do trig to solve reasonably common cases that we have
>> a problem.
>>
>>> but, given the limited use cases ("I just want
>>> a gradient at this angle"), (2) might make more sense in its
>>> simplicity.
>>
>> Can we recall what the use-case was for angle+point in the first
>> place?  It would, I think, simplify the mental model of things
>> considerably if that can be dropped.  Then you'd have only three ways
>> of specifying a gradient - angle, point, and default, and all three
>> will work intuitively.
>>
>> ~TJ
>
> Ah, a closer reading of your proposal shows that what I call (2) above
> is exactly what you already proposed in your <angle> paragraph. At
> first read through I had thought you were suggesting that the angle
> just specifies that the starting point snaps to the closest corner,
> and that was its only functionality. A diagram here would clear up a
> lot.
>
> Simplifying to the three cases you give (point, angle, default) would
> seem to make the most sense. The dual <bg-position> and <angle> form
> could be eliminated, as it can be easily specified by an angle and a
> first color stop calculated in the fashion you mentioned above.
>
> Would (point [, point]?), angle, default work and not add to the
> confusion of this discussion? From what has been said it seems like
> specifying an end point makes the most sense to some.
>

I sketched a quick diagram that might help (with apologies for the lengthy url)

http://lh6.ggpht.com/_K6wA3xN79Qs/SvSmsPplRKI/AAAAAAAAAcc/QtG6Jt4I-ys/s800/gradient-angle.png

Note that this is the default behavior for Illustrator gradients when
an angle is given but not end points: it assumes you want to
completely fill the selected shape and that the color stops at 0 and
100% should occur at the last pixels possible. That behavior is
equivalent to Tab's recommendation for the <angle> parameter, as long
as no background position is specified, and what I think one would
expect if just an angle was specified (ignoring for now the formula
for specifying how to select a "starting" corner based on the angle).

Incidentally, if you change the Illustrator artboard to have its
origin in the top left and have y increase downwards, selecting a
linear gradient with angle 60 degrees puts the 100% colorstop 60
degrees clockwise from 0 degrees, exactly as you'd expect if you think
of the angle as rotating a direction arrow in screen space. For what
that's worth.
Received on Friday, 6 November 2009 22:58:37 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:22 GMT