From: David Singer <singer@apple.com>
Date: Wed, 8 Sep 2010 09:59:25 -0700
Cc: fantasai <fantasai.lists@inkedblade.net>, Simon Fraser <smfr@me.com>, www-style list <www-style@w3.org>
To: Tab Atkins Jr. <jackalmage@gmail.com>
```
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

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