Re: [css3-images] Linear gradients feedback

On Wed, Sep 8, 2010 at 9:59 AM, David Singer <singer@apple.com> wrote:
> 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).

Ah, yeah, I wasn't thinking thoroughly enough.  Sure, a relative angle
from either a horizontal or vertical line would let you make an
absolute angle.  I think this level of indirection is somewhat
unfortunate, though - you first have to think about which reference
line to establish, and then you have to consider what angle you want
to measure off of it.


>> 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).

Actually, my proposal allows for portions of the gradient outside
[0,1] to be shown.  Right now there's no way to *explicitly* give an
end-point, but the implied end-point won't be on an edge unless the
starting-point is, and I've been meaning to add an explicit end-point
argument for some time.  (I have an email where I said I would from
way back in the day.  I don't know why I didn't make the edit some
time ago.  Right now I'm just waiting for the other feedback to
stabilize so I can make all the edits in one go.)

~TJ

Received on Wednesday, 8 September 2010 18:21:42 UTC