Re: [css3-images] Linear gradients feedback

On Aug 30, 2010, at 12:42 PM, Tab Atkins Jr. wrote:

> On Sun, Aug 29, 2010 at 3:14 PM, Simon Fraser <smfr@me.com> wrote:
> 
>> A second reason to try to avoid these branches in the gradient algorithm is because
>> it makes interpolating between them for animation harder. Without a canonical
>> form, you can't map all inputs to a common representation for interpolation.
> 
> Correct, you can't.  Angle-based gradients and no-angle gradients
> calculate their positions in fundamentally different ways which cannot
> be reconciled without losing information.  Angle-based gradients have
> an additional constraint that no-angle gradients don't have.  Even if
> we did define a shared default for the first <bg-position>, there is
> *no way* to define a default <angle> for both cases.  The mere
> presence of an <angle>, no matter the value, adds an additional
> constraint to how the gradient positions itself that can't be
> generally replicated in the two-point gradient.

Once we're able to do transitions/animations on gradients, I'd like the story
to be simple. If there are two forms of linear-gradient that are not interpolatable,
I think they should have different function names, otherwise the spec that
describes the transitions will need a whole lot more "if that, then this" logic
to specify which interpolations are possible.

If you use different function names, then it's very easy to say "transitions
between different gradient functions are not possible".

> 
>>> In either case, missing points have consistent, well-defined default
>>> values.  The defaults are just completely different between the two
>>> cases.  I believe this is necessary to make the two cases actually be
>>> useful.  Simon's proposal for always defaulting the starting-point to
>>> the top-left is insufficient for either case.  If the angle is absent,
>>> it makes the default behavior a diagonal gradient, when the most
>>> common gradients on the web and elsewhere are vertical and horizontal.
>>> If the angle is present, it makes the only useful angle values be
>>> between 0deg and -90deg - 0deg to 90deg and 180deg to 270deg have
>>> unintuitive results, while 90deg to 180deg appears to have no effect
>>> at all in most cases (it draws the gradient completely outside of the
>>> box unless there are color-stops with positions lower than 0%).
>> 
>> I was trying to think along the lines of considering the two
>> <bg-positions> not as endpoints of the gradient specifically, but
>> as the corners of a virtual box that bounds the gradient (following
>> the "extend to the edges" logic that exists in the spec). Unfortunately
>> this doesn't solve the problem of having sensible defaults. The gradient
>> 
>>    linear-gradient(top 45deg, ...)
> 
> That never did extend from the top-left to the bottom-right.  It
> starts in the top-center, actually.
> 
> 
>> would no longer extend from the top-left to bottom-right corners.
>> 
>>    linear-gradient(top left 45deg, ...)
>> 
>> would, however.
>> 
>>> I believe that the current level of "smarts" used in differentiating
>>> the defaults of the two cases is the minimum necessary to make the
>>> syntax useful.  The benefits of simplifying it further would be
>>> strongly outweighed by the downsides of the bad defaults, in my
>>> opinion.
>> 
>> Fundamentally, there are two ways to describe a linear gradient; either as
>> two end points, or a start point (or center point), angle, and length.
>> 
>> That argues for two forms:
>> 
>>  linear-gradient(<bg-position> <bg-position>, ...);
>> 
>> and
>> 
>>  linear-gradient(<bg-position> <angle> <length>, ...);
>> 
>> This latter form would be more useful if <bg-position> specifies the center-point,
>> because then any angle works. A length of 100% could be specified to that which
>> has the gradient extend to fill the box. The defaults are a little tricky; you'd
>> want the <bg-position> to default to center, and <angle> to 90deg for a vertical gradient.
> 
> Wouldn't this still suffer from the same interpolation problems?  Is
> there a hidden benefit to doing it this way that I'm missing?

No, you're right that it does. I was trying to get back to first principles, to see if there's
some other solution.

> Regarding the actual proposal:
> 
> So, if <bg-position> was the center point for the gradient, I suppose
> the starting-point and ending-point for the gradient-line are based on
> the old "where a line perpedicular to the gradient-line would
> intersect" corners based on the <angle>?  Where are the 0% and 100%
> points located for color-stops?  Making the <bg-position> specify the
> center-point seems to be sacrificing both readability and writeability
> for the purpose of gaining a definite default value, which I think is
> backwards.
> 
> If it's specifying the starting-point, then going with a <length> or a
> second <bg-position> seems about equivalent.  I think I argued in the
> old threads that if you want an angle-gradient of a particular length
> you can just specify those lengths in the color-stops.

Using a combination of two positions and an angle is awkward, because one of
the points may no longer lie on the gradient axis. That's why the point/angle/length
combination seems more natural here.

Simon