Re: [css3-images] Proposed Gradients changes

On Thu, Nov 18, 2010 at 8:07 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
> 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.

I still disagree that the indirection required to understand how to
make a corner-to-corner gradient is a good thing.  I accept that
having angle gradients is good, just not that they're the best
solution to every problem.


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

I agree, actually.  However, it does address a *few* cases, and makes
interpolation easier to talk about, so still a net win I think.


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

Your approach doesn't scale to radial gradients, though.  I'd much
prefer to solve the two problems in the same way if it makes sense to
do so, and it does, so I did.


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

Right, but in a good way; the gradient you get in the middle of the
interpolation is, in some sense, actually halfway between the two
endpoint forms, and will react to changes approximately halfway
between the way the two endpoint forms do.


> 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 don't think that's a useful question to ask most of the time during
a transition.  (And I think we can solve that at the CSSOM level when
it is useful, by exposing the actual interpolated value as a property
of the interpolate() function's interface.)


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

It does, but I still think the argument in general isn't strong enough
to influence my decision.


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

I think we're sticking with "you have to have the same number of color
stops", or else you fallback to general image interpolation (a
crossfade or whatever).  That's what I'll be specifying for now, at
least.

(There's a middle ground where we can fallback to just doing
color-interpolation at each point on the gradient line, but I'm not
sure I want to do that.  I don't think that allows an explicit
intermediate form in the general case.)

~TJ

Received on Thursday, 18 November 2010 16:54:53 UTC