Re: [css3-images] Linear gradients feedback

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.

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

~TJ

Received on Wednesday, 8 September 2010 03:50:15 UTC