Re: [css3-images] Changing the angles in gradients

On 5/18/2011 02:27 AM, Brad Kemper wrote:
> On May 17, 2011, at 3:33 PM, "Eric A. Meyer"<eric@meyerweb.com>  wrote:
>
>>>> On 05/17/2011 12:57 PM, Tab Atkins Jr. wrote:
>>>>> So, we have three choices:
>>>>>
>>>>> A) Keep the angles as they are, with 0deg=East and 90deg=North
>>>>> B) Switch to screen-coord polar, with 0deg=East and 90deg=South
>>>>> C) Switch to bearing angles, with 0deg=North and 90deg=East
>>    As an author, I vote for C.  It's consistent with other angles such as transformation rotation, where a 90deg rotation turns an element's top from "North" to "East"-- and frankly, most of us are familiar with bearing angles but don't remember polar angles from school at all.  Blame GPS devices, blame a conspiracy of cartographers if you will, but I think way more people will take naturally to C than A.
> My GPS never talks about angles and degrees when it talks to me.
>
> But all the design and editing and publishing software I've used in like the last 25 years (from Aldus, Quark, Macromedia, Adobe, etc.) has always indicated linear direction with zero pointing right and 90 pointing up. And they all, IIRC, also had zero coordinates in upper left and positive coordinates down and to left. So I completely disagree with your premise.
Indeed, one of the strong points here is how graphics software (most of 
them) approach the angle, which is 0deg=East, 90deg=North. That makes 
the most natural setting to be the current one (A), at least to the 
people that also design.

But at the same time, applications make use of handles to aid designers 
in choosing the direction/angle.
CSS doesn't have that, only numeric values.
This means that it's going to be much more difficult for someone, who 
isn't a designer, to comprehend an angle interpretation chosen by 
graphics applications, than a designer that also codes CSS.

I believe that the most important fact to consider here is that other 
properties use clock-wise rotation (90deg = top becoming right).
Even shorthand properties are CW.
The current angle setting for gradients however, is based on CCW 
rotation, which makes it inconsistent with other properties, and makes 
less sense to anyone that isn't a designer.
Even in graphics applications, rotation individually (as an action) is 
relative to a current position, and always works CW for positive angles.

This means that it's much more important for CSS gradients to switch 
from current A (CCW) to B or C (both CW).

Now, if CW would be established for gradient rotation, the only thing to 
determine would be the initial direction.

The most common setting, also noticed in graphics software, would be 
from left to right (horizontal), for their 0deg position.
However, authors are most commonly faced with creating vertical 
gradients, because of the way most pages extend content vertically and 
adjust to width changes. This means that, C would make much more sense - 
having the initial position to first color being top, and last color 
bottom (0deg).

Although at first I thought C would be ideal, I believe it would 
completely confuse designers, since it's the most different from what 
graphic applications provide.

This is why I now think that B (0deg=East and 90deg=South), would 
actually be the best option and would satisfy everyone, including me, as 
follows:
1) authors obtain the CW rotation, which would be the most important - 
designers would require minimum effort to adjust to this
2) initial direction (0deg) would be horizontal, it already being the 
most common initial direction for linear gradients - authors would 
require minimum effort to adjust to this, especially since the current 
setting in use (A) is very similar.

Note: By using the term 'designer' I was referring to authors that have 
design as a primary skill

>> At 14:52 -0700 5/17/11, Brad Kemper wrote:
>>
>>> Also, authors are using gradients now, with prefixes. Changing the meaning of such an important part of the syntax at this point, to mean something opposite, would mean breaking Web sites, with little hope that they could be fixed by authors in a way that still supported multiple versions of multiple browsers.
>>    That's why we have prefixes, as far as I'm concerned-- to let implementors fix bugs and keep pace with changing specs.
> How does that help authors who are already using prefixes for 4 browsers, and users who update at different paces? It doesn't. The authors would have to remove all the prefixed gradients, and rely only on the raster images that they had in there as fallbacks.
It doesn't, and it shouldn't.
I couldn't agree more with Eric Meyer. Prefixes are being provided by 
implementors for authors to test and make use of early specs, not to 
release production versions. Every author knows that prefixes can change 
at any time, and where their use is mandatory they need to be constantly 
monitored and updated according to implementor changes.

Mihai Potra

Received on Wednesday, 18 May 2011 08:44:29 UTC