Re: linear gradient angles [was radial-gradient() proposal]

On Nov 5, 2009, at 6:29 PM, Dean Jackson wrote:

> I don't like the fact that Y points down that much but it is just  
> the way computers (mostly) work. It sort-of makes sense in a  
> document format because as you add things to the page it grows  
> downwards. The start of the page is at the top.

OK, so the left-top x,y origin point makes sense for documents. As a  
designer, I laid out many pages with 0,0 in the upper left corner.  
I'll bet that even protractor catalogs and geometry text-books were  
laid out that way.

It doesn't change the common-sense way to specify direction. In  
InDesign, Illustrator, PhotoShop, etc. the documents default to having  
the 0 origin in the upper left corner, but angles are STILL specified  
as they are on a protractor. This is not just for gradients, but  
wherever angles are used in those programs. This includes several of  
PhotoShop's layer effects (such as "light direction" for drop  
shadows), the distance/angle move tool in Illustrator, and of course  
the gradient directions.

Even Apple's iWorks (in Pages, at least) follows the traditional  
conventions for gradient angles (and rotation!) and the upper-left  
zeros for planar coordinates too. I hope you are not suggesting that  
CSS is not for people who use Apple products!

So here are 4 things I take as truths:

For charts that plot numbers on two axes, people are used to seeing  
the zero for both axes in the lower left corner.
For electronic documents (and sub-documents, images, etc.), people are  
used to seeing the zero for the x,y coordinates in the upper right  
corner.
For places in software where an angle is used to indicate direction,  
90 degrees is almost always used to indicate up (North, if we use map  
coordinates), zero to indicate rightward (East), and 45 to indicate up  
and to the right (NE).
At some level of programming and math below the level most designers  
and authors deal with, there may be some relationship between the  
coordinate system and what a positive number angle means.

I'm not a mathematician, so #4 part matters little to me, and is  
likely to matter just as little to the majority of authors. Many  
authors are designers though, or use design software, and would find  
it distinctly backwards from common sense to put a minus sign in front  
of all their angles.

Consider if a editing program like Dreamweaver or even Safari's Web  
Inspector implement a UI control to set the direction of a gradient in  
CSS. This would very likely be either a single numeric entry field (to  
enter the angle), or a little circle where you can click on the  
perimeter to get a radii to point to it (as in Adobe apps), or often  
both. The angle text field would most likely be consistent with other  
software and common-sense expectations. So if it had 90 in it, and the  
source code CSS had -90, it would be very confusing. People would have  
two different ways of talking about direction: the common sense way if  
they are using software UI, and the CSS way that requires a minus sign  
or normalization to a backwards 0–360 range.

> People have been dealing with this for years without any known cases  
> of brain explosion. I think keeping consistency is more important.

Well, preventing head explosions is a laudable goal, but I would  
settle for picking the most reasonable, intuitive way of specifying  
angles. Consistency with tradition and expectations is more important  
than mathematical consistency between an angle used for rotation and  
an angle used to indicate direction.

What designers and most "ordinary" people have been dealing with for  
years is that 90 degrees is "up" in reference to the 180-0 reference  
line, and that the 180-0 reference line is horizontal (on a paper or  
computer screen or diagram, when it is not being applied to some  
existing angle that you want to measure from).

On Nov 5, 2009, at 6:41 PM, Dean Jackson wrote:

> I realize it is backwards to you, but there is 20+ years of CG  
> research and use that has managed to survive with a Y-down  
> coordinate system.
>
> In the early days of SVG there were heated arguments about this. I  
> was pushing for Y-up but in the end it made sense to go for  
> compatibility. I don't think anyone suffered too much.

Even with Y-up, it doesn't mean linear directions have to be specified  
backwards too.


>> Or is it just rotate() and skew() in SVG? Because frankly, if so,  
>> then I don't have any problem at all with linear directions  
>> following the protactor convention, and transforms following the  
>> SVG convention. If someone wants to match a gradient to a rotated  
>> object, they can easily add a minus sign.
>
> But you can't?

Of course I can; why wouldn't I? If I had a 30deg gradient  and I  
wanted to rotate an element to align with it, I would use translate to  
rotate that object -30deg. Or vice versa. No big deal. The signs do  
not need to match between an angle indicating a linear direction and  
an angle indicating a rotational motion, because for most people these  
are two different things.

> Surely compatibility and interoperability are more important in  
> standards? You have specs that have been deployed for many years,  
> based on technologies that are even older.

With rotation and the normal, common meaning of "angle", it is still a  
30 degree angle whether you rotate it clockwise or counterclockwise.  
It is an SVG tradition that positive numbers mean clockwise. And I am  
fine if "translate" wants to be consistent with that. But most CSS  
authors are not SVG authors, but are very familiar with specifying  
angles according to the protractor tradition. How will CSS having that  
consistency with expectation break compatibility and interoperability?

>> Brendan has indicate that there are bloggers out there commenting  
>> on the current transform implementations as being buggy or wrong  
>> for going clockwise with it's degrees. Just wait until we are all  
>> asked to flip our protractors over and read the numbers backwards  
>> in order to specify direction! It is completely unintuitive to the  
>> average person, for whom 90 degrees is up.
>
> Bloggers complain. We can't even agree here so it seems  
> understandable that a blogger without context might not realize why  
> a particular decision was made.

OK, then, take a poll of designers and authors. Ask them, "If you were  
creating a gradient from back to white, and specified a 90 degree  
angle for the direction of the angle, which color would you expect to  
be on top?" If you get a reasonable sized survey sample, and they  
disagree with me on that, then I'll shut up about this.

> However in this case it is a fairly small use case (compared to axis  
> aligned gradients or using two points)

I disagree with your parenthetical. In every software I've seen where  
linear direction can be specified numerically, a single angle number  
is used. Using two coordinate points to indicate where a gradient  
starts or ends is, for all but a tiny, tiny fraction of use cases,  
completely redundant to using percentages or lengths to indicate where  
a particular color (such as the first or last color) should go.

> , it is immediately obvious to the author what the problem is and  
> easy to fix.

Right back at you. The same can be said about correcting the problem  
when a SVG-crazed author has to specify a direction according to more  
normal expectations.