Re: [css3-images] Proposed Gradients changes

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


>>> 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 think you're vastly exaggerating the complexity, and further
exaggerating how much complexity is saved by your suggestion.

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.


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

All gradients work the same way.


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


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

~TJ

Received on Thursday, 18 November 2010 18:23:09 UTC