From: Tab Atkins Jr. <jackalmage@gmail.com>

Date: Fri, 6 Nov 2009 11:55:43 -0800

Message-ID: <dd0fbad0911061155gbb61a9fm26e00fc3e3fd9225@mail.gmail.com>

To: Brendan Kenny <bckenny@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>

Date: Fri, 6 Nov 2009 11:55:43 -0800

Message-ID: <dd0fbad0911061155gbb61a9fm26e00fc3e3fd9225@mail.gmail.com>

To: Brendan Kenny <bckenny@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 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. ~TJReceived on Friday, 6 November 2009 19:56:30 UTC

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