Re: Linear gradients, Transforms and angles...

On Sep 24, 2010, at 8:08 AM, James Elmore wrote:

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

Since a gradient is an image, this can already be done via the transform  property. If you wanted to apply transforms to just background images, then you'd need 'background-rotate', background-skew', etc. Maybe one day, but it seems like overkill for just determining a linear gradient direction.

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

I don't think it is insoluble. To accept my viewpoint, one only has to accept that a degree is a measurement of arc, not just of rotation. As such, an arc has no notion of direction, only of amount. 

It CAN be used to determine the amount of a rotation, and it has been determined already that when put to that use, positive numbers = clockwise rotations. I have no disagreement with that at all. 

It can ALSO be used to define the direction of a ray. To do so numerically, one only has to decide which direction zero points to, and which direction (clockwise or counter-clockwise) the degrees should be numbered. As it turns out, long-standing tradition has already done this for us: zero points to the right, and positive numbers progress counter-clockwise toward 360. [A different convention is used for "bearing", which presumes starting with a strong concept of "forward" or "north", but those don't really apply to CSS.] That direction of that ray determines the linear direction of the linear gradient. It is really just a labeling system for linear direction, just as are "north", "left", "bottom left to top middle", "10% grade", etc. [grades as percents are also indicated on a counter-clockwise scale from a horizontal zero, BTW], and not necessarily of rotation.

It is not confusing at all; it is really quite simple (which is why it is used in design software, drawing software, image-editing software, math books, etc. to numerically indicate a angle of linear direction as a single 1-3 digit number) and not at all inconsistent with the separate idea of which way rotations should rotate. For linear-gradient, he degrees are being used to indicate the amount of difference in linear direction from a default linear direction of 0deg. Nothing is conceptually rotated, regardless of what goes on at the implementation level.  

Of course, this linear-direction-labeling convention should be made explicit in the spec, but we don't need to inject wording about how it flies in the face of every other understanding of degrees in CSS. It does not do that, and is not inconsistent, any more than the difference between positive "right" being a different direction from positive "left" when positioning. Because degrees of arc, like measurements of distance, are by themselves agnostic with regard to direction.


> If a question seems to have no good answer, perhaps it is because I was asking the wrong question.

Not a bad approach, but I don't think it is the wrong question in this limited case.

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

Received on Friday, 24 September 2010 16:28:32 UTC