Re: [css3-images] Proposed Gradients changes

On Nov 18, 2010, at 10:22 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Thu, Nov 18, 2010 at 10:10 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> 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.
> 
> Yes you can.  You don't use use extra dashes, but it's perfectly fine
> to say "bottom left to top right".  

I misread the background-position spec then. It's different when you want to use a number apparently (like '0 top' to '100% bottom', which means the same thing in your syntax). 

> The bg-position syntax explicitly
> allows this sort of thing.  (I usually write it the other way around
> purposely so I'm less likely to screw up the order when I use numbers,
> but still - I'd much rather write "linear-gradient(bottom left, white,
> black)".)

If I had my druthers, I'd go back and change the border/margin/padding/etc. values to start on the left, instead of the top, so they wouldn't be so different from properties with H and V values. But that won't happen, and is off topic. 

> 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.
> 
> And you have simplicity.  For the rarer cases when you do need to be
> more explicit, though, it's also very simple to specify (you don't
> have to do any weird contortions or trig to figure out how to express
> an arbitrary gradient in the constraints available to you).

I can't think of any real use case that would require trig. What gets complicated is figuring out where the color stops actually end up once you layer a one-dimensional color stop distance system on top of a two dimensional double point system that not only indicates a direction (once you do the trig to convert it into an actual 2-D linear direction), but also unnecessarily replicates the functionality of determining where the first and last colors go. 

I don't see how it is a weird contortion to add a keyword for letting the angle of a diagonal conform to the image dimensions, if that's what you're after. If it's not what your after, or if you're working with verticals or horizontals, then angle alone is enough. 

> I think you're vastly exaggerating the complexity, and further
> exaggerating how much complexity is saved by your suggestion.

I'm not. The complexity of bg-position for this is just extra kruft to muddy the waters of what is otherwise a simple and easily understood angle that requires no explanation. '0 bottom' is vastly unintuitive as an indication of a linear direction. The ability to draw a box within the image box is completely unneeded. All we need is a direction and the color stops. 

Even if you don't like my 'as-square' keyword, I'd be happy enough if we just reduced your proposal down to something like this:

Linear-gradient([<angle>|<keyword>], <color-stop-list>)

...where the keyword would be one of eight direction indicators:

top-left-to-bottom-right
bottom-right-to-top-left
top-to-bottom
right-to-left
etc. 

And then the computed value of the direction would always be an angle. This is vastly more simple that bringing over the entire bg-position vocabulary/syntax and plugging into two spots and having mirrored hidden values. If a new user saw either of the filling two images, he would immediately know how it works:

Linear-gradient(45deg, black, white)
Linear-gradient(bottom-left-to-top-right, black, white 100px)

At worst, it might take one extra try if he expected degrees to work with a different zero point or progression than they do in graphics programs. The same cannot be said for the vast number of other ways possible via double bg-position plots. 

Can you really not see how what I'm suggesting is a much simpler system?


> Basically, we had this discussion back when I was first developing the
> syntax.  Neither of our arguments have significantly changed, and
> neither has my conclusion.

In other words, I'm still not satisfied with the draft, and you still won't make changes to address my concerns. 

> 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 don't understand the question.  What is the "that" you are asking
> about in the last question?

What is the 'interpolation' function useful for? Simon indicated that the syntax should be simplified, especially for use in transitions and animations, and the result looks like added complexity. Now we can have a bg-position AND color stop positions inside a gradient function, inside an interpolation function, inside a background (most often) with it's own background position. It sounds complex and I'm honestly wondering how the 'interpolation' function helps or where it fits in. 

> 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.
> 
> That's fair.  But I'm the editor of this particular bit.  ^_^

And I'm a voter. I suppose I could create my own competing draft, but I was hoping for more cooperation, not competition.