Re: [css3-images] Proposed Gradients changes

I still feel strongly that my approach (to linear gradient) is much simpler all the way around, and easier to understand in a glance. The first argument is for direction only, and when you want to know the direction of the gradient, there it is. For transitions, you interpolate between computed/used values, which at any point are still just angles to indicate a simple linear direction and nothing more. What could be simpler? My keyword approach to doing diagonal directions that conform to the element shape would only affect the specified value, and thus is irrelevant for interpolating the used values in animations and transitions. And if you want to know where the first color starts or the last color ends in angle syntax, you look at the color-stop list, and nothing else. 

The plotting of two 2-dimensional bg-position points is simply unnecessary in all but a few extreme edge cases, and even those cases can still be handled handily in other ways. 

My approach does not suffer the same interpolation problem that you mention below (45deg _is_ halfway between 0deg and 90deg), and does not require a separate 'interpolate()' function to deal with it. The computed value can be round-tripped, and the specified value would be the only one with the keyword in it. It is unlikely you would ever need the specified value for an interpolated value, but you could convert the computed value to a stretchable keyword-included value with a little math, and hopefully the CSSDOM would let you easily see when one end or the other of the transition had the keyword or not. 

Note that even with your 'interpolate()', you have a similar problem of being somewhere between stretchy and non-stretchy angular direction, if you do something like  interpolate(linear-gradient(45deg, black, white), linear-gradient(left bottom, black, white), 20%). I don't see how it makes that situation any better, but it does make the answer to the question "what is my gradient direction right now?" a lot longer and considerably less clear.

I didn't realize that the missing 2 <bg-position> syntax (in which the second one is not determined automatically) was removed unintentionally.  If added back in, in makes my argument #3 <http://www.bradclicks.com/cssplay/linear-gradient/index.html#KISS> even stronger, because that then adds back in an infinite number of ways to specify the same direction (instead of just one way with angle syntax).

By the way, a separate difficulty with interoperation that we both have is, what do you do when the number of color stops is different in the two gradients you are transitioning between? Are extra stops brought in from the far side right before the last stop, or fade into their new positions, or what?

On Nov 17, 2010, at 6:06 PM, Tab Atkins Jr. wrote:

> This is an announcement of my planned changes to gradients in the
> Image Values spec (which turned out to be minor), based on my previous
> discussions with the group, particularly Brad and Simon.  If nobody
> objects in a few days I'll make the edits.
> 
> 
> Simplify linear-gradient
> ------------------------
> 
> In retrospect, allowing you to mix together endpoints and angles was a
> bad idea.  There's basically no use-case, so it's just unneeded
> complexity in the descriptions and implementations.
> 
> I'll be changing the syntax so that you can provide *either* one or
> two endpoints *or* an angle, not both.  The one-endpoint syntax and
> angle syntax will work identically to how they do now; the
> two-endpoint syntax should be obvious, and its omission was frankly
> just an oversight.
> 
> I'll also be very slightly tweaking the treatment of an angle value.
> This will have no effect on the display of gradients, but will affect
> interpolating them (see below).
> 
> 
> Complete radial-gradient
> ------------------------
> 
> With the addition of the two-endpoint form of linear-gradients, you
> can now explicitly express any possible linear gradient.  The same is
> not true of radial gradients, which currently rely very extensively on
> implicitly sizing things relative to the box's shape and size.
> 
> I'll be changing the syntax so that the second argument, which
> currently determines the shape and size, can instead take two lengths,
> which determine the lengths of the ellipse axes in the x and y
> directions.  Combined with the existing ability to specify an
> arbitrary center point in the first argument, this will allow you to
> express any possible radial gradient.  (The current "<shape> <size>"
> value will still be allowed too, of course.)
> 
> 
> Fixing interpolation
> --------------------
> 
> Simon was concerned that there's no clear way to interpolate between
> two gradients that aren't specified in the same way - for example,
> transitioning between two linear-gradient backgrounds, one specified
> as "left" and the other with "45deg".
> 
> With the above additions I have fixed this issue.  When transitioning
> a gradient image, first convert the two endpoint forms into the
> explicit forms given above (for linear gradients, the two-point
> syntax; for radial gradient, the point-and-two-lengths syntax).  Then,
> naively interpolate each component separately.
> 
> This isn't perfect in some cases - for example, the midpoint between
> "0deg" and "90deg" for a linear-gradient background on a 100px by
> 200px box is *not* a "45deg" gradient, but rather a "25px 150px to
> 75px 50px" gradient, which is angled at about 63deg and has endpoints
> inside the box.
> 
> I don't believe this is a problem in practice - I believe that
> rotating a gradient in a transition is a somewhat odd thing to do.  As
> well, this can be addressed with additions to Transitions to allow
> keyframes to be used for a transition.  (This has been previously
> discussed, and is something I'll be heavily lobbying for in
> Transitions 4.)
> 
> 
> Intermediate Forms during interpolation
> ---------------------------------------
> 
> Simon was additional concerned with what value to return for the
> intermediate forms while a gradient was being interpolated.
> 
> There are two possible approaches.  The first is simply to return the
> explicit-form gradient that was calculated for rendering purposes, per
> the previous section.  This has a major downside, though, that
> round-tripping it changes the essentially nature of the gradient.  For
> example, if the two endpoint forms were "radial-gradient(ellipse
> contain, ...)" and "radial-gradient(ellipse cover, ..)", both change
> shape/size if the view box does, but an explicit intermediate form
> (something like "radial-gradient(center center, 100px 50px, ...)")
> won't.
> 
> So, I will instead be pursuing a slightly abstracted approach.  I'll
> introduce an "interpolate()" function which takes two images and a
> percentage, and represents the interpolated image between them at that
> percentage of interpolation.  The interpolate() function can exist as
> a specified or computed value; it is converted into an explicit form
> per the previous section at used-value time.
> 
> For now interpolate() will only be defined for gradient arguments, but
> it can potentially be used for *any* interpolable value.  If this is
> interesting, we can lift the general definition out into Transitions,
> and change Image Values to just specify its effect when passed
> gradients.
> 
> To provide a concrete example, say you are transitioning the
> background-image property, which is changing from
> "radial-gradient(ellipse contain, white, black)" to
> "radial-gradient(ellipse cover, white, black)".  If the author queries
> for the animated value 20% of the way through the transition, the
> value returned to them is "interpolate(radial-gradient(ellipse
> contain, white, black), radial-gradient(ellipse cover, white, black),
> 20%)".
> 
> Any objections?  If not, I'll make the edits next week.
> 
> ~TJ
>

Received on Thursday, 18 November 2010 16:08:17 UTC