Re: Linear gradients, Transforms and angles...

Reading this (extracted text, below), I had a thought: What if the group agrees to separate the PRODUCTION of a linear gradient from the POSITIONING of the gradient? (Wait a few more sentences before you send flames, please?)

The existing transform abilities would allow the placement of gradients, by skewing, rotating, zooming, positive and negative offsets in both X and Y directions, and combinations. That makes the problems with angles starting in different places and rotating in different directions moot, because that would all be done with transforms. It also makes the code to produce a gradient simpler, both for the implementors and for the users. It does require an extra step for the users to position/transform the (default?) gradient. (This could be a problem, but a possible solution might be to create a combination, such as 'gradient_and_transform' which takes attributes for both properties.) At any rate, this proposal guarantees that the users will not be confused by angles which start in different places and rotate in different directions. And it offers a solution which, once learned by the users, will work exactly the same for any element (or at least any which may be transformed, I haven't read that specification, yet.)

I have been (mostly) following the voluminous discussion of this, and the discussion below (and the total number of emails the last few days) triggered a 'rule' I often use when a problem seems insoluble: If a question seems to have no good answer, perhaps it is because I was asking the wrong question. And then I started thinking about if the problem was with the gradient logic or something else. So, does this (separating the thought of gradients from their positions) help, even a little, to get the discussion moving towards to a solution?

On Sep 23, 2010, at 5:48 PM, Brad Kemper wrote:

>>>> I think users want rotations (transforms) and gradients to be consistent --
>>> 
>>> Well, you do, clearly, any way.
>> 
>> Consistency within a specification is way more important than rough consistency with other tools and other systems.

[...]

> Linear gradients. The thing about them is that they are linear. As in "line". A straight direction. They are therefore different from, say, 'transform:rotate()' in which something is actually rotated. Most authors will not think of a 45deg linear gradient as being a left-right angle that has been rotated 45deg. It is just a direction, a straight direction. NOT something that has been rotated. That direction is measured in degrees because it can be thought of as a ray pointing outward from it's starting point, as if you centered a protractor on that point. There is a relative distance of circular arc that (when measured in degrees) tells you what direction the ray is pointing, but the ray itself is one-dimensional in its direction, unlike an actual rotation. 
> 
> So just because linear directions and rotations both are measured in degrees does not mean that you can't intuitively have positive numbers mean clockwise for _rotations_, but still follow the standard geometry convention for specifying _linear_ direction. 
> 
>> 
>>>> not have to remember that there are two somewhat intuitive, but different, conventions at work depending on what they are working with.
>> 
>>> 
>>> That is exactly what you are asking designers and other authors to do when they use normal angle notation everywhere in life except CSS, SVG, and Canvas.
>> 
>> I am asking for the spec. to be consistent within itself.  Consistency with other systems is secondary.

<James />