Re: radial-gradient() proposal

On Nov 6, 2009, at 2:55 PM, fantasai wrote:

> Brad Kemper wrote:
>> On Nov 6, 2009, at 11:07 AM, fantasai  
>> <fantasai.lists@inkedblade.net> wrote:
>>> I strongly disagree with disregarding the angle here. If I specify  
>>> an
>>> angle, I should get that angle, not some random transformation of it
>>> depending on the size of the box.
>> So have you considered the advantages and still disagree with the  
>> notion of having a switch between two different modes? Or are you  
>> just rejecting the entire notion out of hand because you disagree  
>> that the default mode should be "act more like other images"?
>
> I strongly disagree that the default mode should be to "act like a  
> resized
> image, even if it means disregarding that the author explicitly gave  
> an angle".
> One of the advantages of doing gradients in CSS is that you draw the  
> gradient
> into the size of the final box: there's no need to draw it into a  
> square and
> then resize. This is why mixing percentages and lengths works. (Or  
> really,
> why lengths work at all.)
>
> As for a switch to draw the gradient into a square box before resizing
> it to actual size... that seems rather silly.

That's kind of harsh.

> I suppose I might be convinced
> otherwise, but I don't understand why you wouldn't want to just pick  
> two
> points.

Well, I've explained why before, but here it is again:

For the most part, picking two points for the colors to start or stop  
on is completely redundant to specifying one distance/percentage for  
either or each of the beginning and ending color stops in the <color- 
stop> list. The one compelling reason for picking points instead is so  
that you stretch from one corner to the other (or to and from some  
distance from those corners). This need for extra measurements is  
eliminated via a keyword, which can let the angle either stay a fixed  
angle or to stretch with the corners.
In every other design or layout program that designers use where a  
gradient direction can be indicated numerically, it is ALWAYS an  
angle. It is familiar, short, simple, and obvious. If we insist on  
having a pair of x/y coordinates (or worse for clarity, just one set),  
it will be the only thing in most authors experience that specifies a  
gradient direction that way. It's like if I asked where to lay down a  
hall rug, and instead of saying "between the second doorway and the  
next-to-last doorway in that hallway there", you instead give me the  
longitude and latitude of those doors. For most people creating  
gradients today, it is "pick 2 colors and an angle". Even when using a  
gradient tool for more control, it is often with the shift key held  
down to constrain it to one dimension instead of 2, with the thing you  
care about being the 1D distance from the beginning or end, for the  
outside colors to stop at along your path (whatever the angle of the  
path, that is what you care about). Moving to one side or the other of  
center of your gradient path doesn't matter as long as you maintain  
the angle you want.
Every time you add more numbers or other units to the property value  
you lengthen it, make it more complex, make it harder to learn, harder  
to write, less clear, and for what? The disadvantages of adding up to  
4 distances or percentages (and a "to" keyword) to the beginning—when  
there are already distances and percentages associated with each color  
stop—really calls out for a little rethinking of some of your initial  
assumptions about the best way to handle corner-to-corner stretching.  
That's what I did, and I was able to replace all that added text and  
numbers with a single keyword. The 'linear-gradient' property value  
can already get long and complex enough once you start adding more  
color stops; I don't want a big string of extra characters at the  
beginning.
In the first linear-gradent example [VI], there are 7 examples of how  
the exact same gradient can be written, and that leaves many out!  
Sure, a couple of them were just unit equivalencies, but even more  
ways to mix and match values for the most complicated way to describe  
a direction were left out. As long as we're throwing invectives  
around, I have to say this is absolutely absurd! Are we trying to  
ensure as much misunderstanding and confusion as possible for  
designers learning this property? Having two completely different  
coordinate systems and locations within the property to say where the  
starting or ending colors falls is just asking for trouble. I can't  
wait until I have to read some CSS created by two different people  
with two different habits for where they specify endpoints, and it   
ends up looking like this: 'linear-gradient(20px 20px to bottom right,  
black -30px, white 100%)'. It is not an aid to learning to have one  
set of up to 4 numbers scale the gradient line, and other numbers in  
another place say where the colors REALLY begin and end. And then just  
to add to the confusion is the complete non-obviousness of what a lone  
'top' or 'center top' is supposed to mean without any mention of the  
other end of the line. It doesn't look like anything meaningful.

For the simple cases (multiples of 90deg, which would likely be far  
more common than anything else), no keyword is needed, and it would be  
written in the common, obvious way (also available in the current  
draft):

	linear-gradient(90deg, red, yellow)

Because the box has perpendicular sides and the example above used a  
multiple of 90deg, there is no need for an extra keyword (its the same  
either way). And with my way that would be THE way to write that, with  
the only variants being 1) changing to other equivalents of 90deg  
(like using rads or -270deg), 2) including or not the optional  
percents in the color stops when they are endpoints or equally spaced,  
or 3) reversing both the angle direction and color order together.  
Simple.

And other angles stay simple by assuming an initial square shape (I'm  
reversing the action of the switch here for you, and I really don't  
much care what the switch is called):

	linear-gradient(45deg, red, yellow)
	/* angle stays at 45deg regardless of box shape: */	

	linear-gradient(45deg stretch-square, red, yellow)
	 /* angle changes based on box shape (thus, stays corner-to-corner) */

If you don't want the gradient to go all the way to the corners, then  
it is still simple:

	linear-gradient(45deg stretch-square, red 20%, yellow 80%)

Remember that the reason we are using CSS for gradients instead of  
SVG, is because we want to make it simple and easy for authors to  
create, read, and edit. We should leave behind as much of the  
authoring complexity and verbosity of SVG as we can, while still  
covering the majority of use cases.

But once you start using a 2D coordinate system to set the gradient  
endpoints, and then overlay a 1D coordinate system inside of that to  
set the endpoints again (the beginning and ending color-stops), then  
you've already made the gradient more complex than any other gradient  
in most authors' experiences. But you get no benefit from that beyond  
what you could get with my simple keyword switch.

Now throw in the ability to mix percentages and fixed distances as  
color-stops in the same gradient path, something that no one actually  
does in practice (aside from 0% and 100% mixed with lengths), and you  
have even more to confound someone trying to make sense of the image  
in a CSS rule.

Now ask them to guess what "center right" or even just "center" by  
itself is supposed to mean for the direction of the line.

There's something to be said for clarity, and gradients written with a  
2D coordinate system when it already has 1D distances available in the  
color-stops just creates too many opportunities to destroy clarity. I  
don't ever want the following to ever be part of CSS:

	linear-gradient(100px center to center 500px, red 100px, yellow 80%,  
black 300px, orange 130%)

Stop the insanity! If someone really needs that much control, they can  
write it this way:

	ur(crazy-gradient.svg)

And yes, I am also suggesting that we also don't really need to be  
able to have fixed distances and percentages mixed together in the  
color-stop list, except when putting all fixed distance color-stops  
between endpoints of 0% and 100%. Keep it simple.


[VI] http://dev.w3.org/csswg/css3-images/#linear-gradient-examples