- From: David Singer <singer@apple.com>
- Date: Wed, 8 Sep 2010 09:59:25 -0700
- To: Tab Atkins Jr. <jackalmage@gmail.com>
- Cc: fantasai <fantasai.lists@inkedblade.net>, Simon Fraser <smfr@me.com>, www-style list <www-style@w3.org>
On Sep 7, 2010, at 20:49 , Tab Atkins Jr. wrote:
>> the first argument is one of the possibilities: b-t, t-b, l-r, r-l, bl-tr,
>> tl-br, tr-bl, br-tl
>> the second is an angle relative to that base vector
>> the two combined give a computed gradient vector, and after that,
>> everything falls out.
>
> Relative angles are actually a substantially different thing than the
> current angles I use. It's impossible to use relative angles to just
> say "give me a gradient at 45deg".
I think that that is 45 degrees relative to the l-r line (i.e. x axis).
> I think that in general relative
> angles aren't very useful. (Personally, I think absolute angles
> aren't too useful either, but I trust Brad when he says they are for
> him.)
>
>> Transitions are then defined as interpolating between the computed gradient
>> vectors, of course.
>>
>> Now we only need one syntax and we can interpolate, and so on.
>>
>> linear-gradient( base-direction, relative-angle, from-color, to-color,
>> {stop%, stop-color}* ) where from-color is defined as from 0% and to-color
>> is defined as to 100%.
>
> While this does let us unify, I think it loses too much useful
> abilities that the current syntax offers.
what do I lose? I think I lose the webkit cases where the start and end points are specifically given, which means that portions of the gradient <0 and >1.0 can be visible, but nothing from your proposal. (And the most complex here gives features yours does not have).
David Singer
Multimedia and Software Standards, Apple Inc.
Received on Wednesday, 8 September 2010 16:59:59 UTC