Re: [css3-images] Proposed Gradients changes

On Nov 18, 2010, at 8:53 AM, Tab Atkins Jr. wrote:

> 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 don't see it as indirection. I see it as directly confronting the fundamental reason for ever using the other syntax: in order to let the element shape affect the gradient direction.

If you mean that saying 'left bottom to right top' is more immediately understandable than '45deg as-square', you may have a point, but the point is weakened by the fact that have to remember the correct bg-position order. You can't say 'bottom-left to top-right', which would be a far more common way to describe those corners, and the way that border-radius does. Which is why in my proposal (at the very end), I suggest that we could still have keyword shortcuts (not exactly a shorthand, but similar), where a keyword like 'bottom-to-top' or 'bottom-left-to-top-right' could stand in for the most common cases (such as '90deg' and '45deg as-square'), while still avoiding the explosion of different ways to specify the same thing, and the other problems I noted.

> I accept that
> having angle gradients is good, just not that they're the best
> solution to every problem.

The best solution would be having one simple syntax that handles all common linear gradient needs. I've noted several reasons why having the second syntax makes things worse, not the least of which is the complex layering of one set of coordinates onto another.

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

As does my proposal.

> and makes
> interpolation easier to talk about,

I completely disagree.

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

That may be a "nice to have", but far less important than my other points, IMO. Radial gradients are much more of a 2-dimensional construct than a simple 1-dimentional direction needed for linear gradients. I'd be happier going the other way, and finding a way to represent the most common radial gradients without bg-position syntax. If the image is being used as a background image, it can already be sized and positioned anywhere, and then allowed to extend over the whole background painting area (possibly with an 'extend' keyword in the background syntax, or maybe just automatically). It seems unlikely that you would need anything other than centered radials or corner-centered radials for list marker images. If you did need something more for, say, border-image, then there is always SVG.

It just seems like we are going way overboard with extended syntaxes to handle unlikely or unusual cases that can be better handled in other ways. I'd much, much prefer simplicity.


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

So does reading the computed value in my syntax, with a more intuitive halfway point (45deg is between 0deg and 90 deg). What is the gain?

>> 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 still don't get what you are trying to solve that my syntax doesn't allow. If you are not trying to easily determine the gradient direction, what is the purpose of having that as a value?

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

We disagree then. And it was just one of the arguments. I don't think the reasons for having a separate bg-position syntax is strong enough to influence my decision to reject it.

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

I think that is fine for now.

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

Agreed.  Stops in the middle should allowed to move around, not just dissolve.

Received on Thursday, 18 November 2010 18:11:32 UTC