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

On 5/18/2011 19:40 PM, Brad Kemper wrote:
> On May 17, 2011, at 7:29 PM, Mihai Potra wrote:
>> CSS doesn't have that, only numeric values.
> Authoring applications do. Consider Adobe, which sells a lot of their software in Suites that include PhotoShop, Illustrator, InDesign, and DreamWeaver. Each of those, except DreamWeaver (the Web authoring application) have ways of setting the gradient by number, using the standard conventions. Once DreamWeaver can set gradient, shouldn't it have a similar way of doing so as the other applications of the suite, which are otherwise consistent? And wouldn't it be weird and confusing to enter 35 in the GUI and have it show up as 55 or 325 or something else in the code view?
>
I was referring to the fact that CSS does not have aiding features to 
define direction, other than by value - while applications have. 
Therefore, it's much more important to have conventions that are easy to 
guess, for CSS authors - which is by ensuring authors consistency with 
conventions in other properties, since CSS is aiming at authors 
primarily, not Adobe products and users.

As for applications, it's all about converting from one relative system 
to another, where applications are the tools for CSS, not the other way 
around.

Besides, I'm more interested in changing the TRBL thinking, than the 
direction which I believe would be best to keep in line with math 
(0deg=East)
>> I believe that the most important fact to consider here is that other properties use clock-wise rotation (90deg = top becoming right).
> If you really, really want to think about a rotation (instead of a straight direction) and want the rotation to go clockwise, then imagine a gear, turning clockwise, that is turning a same-sized circle, in which a pointer on the circle is initially pointing to the right. I say this to show that the notion of pointing in a certain direction based on common conventions is not fundamentally at odds with clockwise rotation.
>
>> Even shorthand properties are CW.
>> The current angle setting for gradients however, is based on CCW rotation
> That is the thing I dispute the most. The degrees in gradients do not indicate a rotation, they indicate a linear direction. No rotation is needed in order to understand the linear direction; you only need to understand what to map the degrees to, and what we have already is by far the most common mapping for translating degrees into a single linear direction.
>
Degrees by definition refer to a rotation, even if it's not an issued 
operation. In order for me to define a gradient's direction using 
angles, I first have to start from the initial (0deg) setting and 
imagine a rotation by which my gradient would achieve the desired 
direction. That would give me the degree I was looking for.
If we wanted degrees in gradients to not indicate a rotation, we would 
have used something else like string values: "top-bottom", "left-right", 
but that wouldn't have been flexible enough.

The current implementation forces authors to imagine an inversed 
rotation, in order to determine the angle they need to define for the 
property - inverse to how I would determine the required angle on other 
properties (TRBL). This is where the inconsistency comes.

Mihai

Received on Wednesday, 18 May 2011 17:50:14 UTC