W3C home > Mailing lists > Public > www-style@w3.org > November 2009

Re: radial-gradient() proposal

From: Brendan Kenny <bckenny@gmail.com>
Date: Thu, 5 Nov 2009 03:29:19 -0600
Message-ID: <ab96c3ef0911050129p677fcffayd554c1d2b8f4b711@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: Simon Fraser <smfr@me.com>, www-style list <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
On Thu, Nov 5, 2009 at 2:14 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
> On Nov 4, 2009, at 10:48 PM, Brendan Kenny <bckenny@gmail.com> wrote:
> On Thu, Nov 5, 2009 at 12:17 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
> [cc'ing my reply to whole list, assuming you meant to do the same...]
> I think that clockwise rotation makes total sense when actually rotating
> something, instead of indicating a linear direction. But for linear
> directions, I think that there is not really anything that is turning.
> Thus using .25turn instead of 90deg for a linear-gradient direction feels a
> little unnatural to me (even though it means the same to CSS), because
> nothing is turning aside from a point of reference. For just indication a
> straight direction, the protractor directions seem most intuitive. Like this
> (showing degrees and radians, and with 0 going to the right, and 90 going
> straight up):
> http://en.wikipedia.org/wiki/File:Degree-Radian_Conversion.svg
> Here is a Java applet from a math site, which shows directional arrows, and
> the resulting angles:
> http://www.mathopenref.com/degrees.html
> [...]
> My intuition says the same, but I also think that the only angle unit
> should be radians, so I can't trust myself here =]
> I think there are two arguments to be made here. The weaker one is
> from the mathematical side: there is an implicit transform in the
> entire view, so any directional vector is also transformed.
> OK. I tend to think of it more conceptually than mathmatically, but I can
> see this.
> Simon's
> point about consistency is much better. I've run across several blog
> entries that already assume that the existing transform
> implementations (giving clockwise rotations for positive angles) are
> buggy or are simplifying things for those who might not remember their
> last geometry course.
> Interesting. I wouldn't say it is buggy, just adhering to a different
> convention. An angle is an angle, no matter where the reference line starts.
> At 2:25 on a round clock, the big hand is 90 degrees (and 270 degrees) from
> the little hand, and vice versa. It is just a common convention in geometry
> to show angles as measured from a horizontal baseline with zero to the
> right, when no other reference line exists. Clockwise is similarly a common
> defaul for rotational motion, due to long-term familarity with clocks, I
> suppose (and screws, volume knobs, door knobs, etc.). For knobs,
> counter-clockwise often means turning them towards their original un-turned
> position. It's possible I have some Western bias here.
> As an example, if an element with a directional
> gradient is near element rotated at the same angle, the intuitive
> result to the author would be for them to be oriented similarly. The
> opposite would probably seem broken.
> Ah. That's a pretty good argument. I hadn't considered that. Hmm. I don't
> know if I'd say it's "broken" per se, but counter intuitive in that
> situation. So you are saying that transforms should change?
> (to say nothing of gradients on rotated elements. i assume the points
> and the angle specified are also transformed; if so, the assumed
> behavior would probably be that angles of the same sign would result
> in a cumulative rotation)
> Sure. That argument flows naturally from the previous one.

Transforms have it right, it can just seem wrong to some at first
sight. Positive rotations go counterclockwise from "east," but when
mirrored downward to screen coordinates that becomes a clockwise

As for gradients, personally I think a given angle should produce a
similar rotation in the gradient as in a transform.
Received on Thursday, 5 November 2009 16:09:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:40 UTC