Re: [css3-images] Linear gradients feedback

On Sep 7, 2010, at 8:49 pm, Tab Atkins Jr. wrote:

> On Tue, Sep 7, 2010 at 8:27 PM, Dave Singer <singer@apple.com> wrote:
>> actually I think I can be vastly clearer and also merge a whole load of
>> suggestions/solutions.  and (the devil of people who used to be in research
>> departments) generalize!  Try this:
>> 
>> Linear gradients.  These are drawn between two parallel lines (the 'from'
>> and 'to' lines), which are perpendicular to the gradient vector.  The
>> intersection of the 'from' line and the gradient vector is less far along
>> the vector than the intersection of the 'to' line. Each of these lines
>> intersects the shape to be filled at the furthest possible extremity in the
>> negative ('from') and positive ('to') directions along the gradient vector.
>> (Which means we don't need to care about what the colors are before 'from'
>> or after 'to' since they are not visible).
> 
> Right, that's basically what I'm going to be using.  I have a slightly
> different wording that I think is somewhat clearer, but accomplishes
> the same result.

I always assumed that you were doing this :)

>> This generalizes your diagram for the 'to' line and uses it for the 'from'
>> line.  It also covers the degenerate cases where the furthest extremity is a
>> line (0, 90, 180, and 270).  It fills from any corner or edge in any stable
>> direction.
>> 
>> So, what fill cases does this *not* cover?  Well, those whose direction is
>> determined by the geometry of the box that they are filling.  Since the box
>> edges are vertical and horizontal (known directions), that leaves us with
>> diagonals.
>> 
>> So, the next more general syntax is where the first argument is *either* a
>> vector direction (number), or one of the four vectors bl-tr, tl-br, tr-bl,
>> br-tl (t[op], b[ottom], l[eft], r[ight], obviously).  We only need the
>> diagonals as a special case.
> 
> I think this is less clear than just reusing the existing
> <bg-position> for the start and end points, defaulting the end point
> to "rotate the starting point 180deg around the center of the box".
> 
> 
>> Ah, but we can deal with some of Elika's incisive question about the axis
>> system in use, if we go for two arguments; then the gradient vector is
>> defined by an angle relative to a base vector.  So, then we have a syntax
>> with two arguments;
>> a base direction, specifying two corners
>> plus an angle relative to that base direction
>> 
>> 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".

Can't you use t-b, 45deg for that?

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

Me too; I think it's more common to define gradients relative to endpoints
in flexible content like web content.

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

It makes it impossible to specify a gradient where the 'from' line and the 'to'
line intersect specific points (e.g. like -webkit-gradient(20px 20px, 60px 80px),
which is something that I believe linear-gradient() needs to make easy.

Simon

Received on Wednesday, 8 September 2010 04:45:13 UTC