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

I think at this point it's pretty clear we're not going to agree, and  
it is a waste of time to continue filling the list with our discussion  
on a relatively trivial issue. I understand your rationale. As I said,  
I was arguing the same way in SVG, but since that battle was lost I  
favour consistency going forward.

Dean


On 07/11/2009, at 5:18 AM, Brad Kemper wrote:

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

Received on Friday, 6 November 2009 18:59:25 UTC