RE: [css3-images] linear-gradient keywords and angles are opposite

[Brad Kemper:]
> On Jun 8, 2011, at 9:59 AM, Sylvain Galineau <>
> wrote:
> >
> >
> > [Tab Atkins:]
> >> On Wed, Jun 8, 2011 at 4:27 AM, Brad Kemper <>
> wrote:
> >>> On Jun 7, 2011, at 11:34 AM, Brian Manthos <>
> >> wrote:
> >>>> Paraphrasing [1]:
> >>>> When specified via angle, the angle can be understood as both the
> >>>> direction ("toward the <angle>") and the ending point ("ends at
> >> <angle>").
> >>>>
> >>>> Paraphrasing [2] and [3]:
> >>>> When specified via keyword, the keyword can be understood as both
> >>>> opposite direction ("away from the <keyword(s)>") and the starting
> >>>> point ("starts at  <keyword>").
> >>>>
> >>>> Is it intentional that these two ways of specifying gradient-line
> >>>> are opposite?
> >>>
> >>> I don't think they are. In [1], the angle determines the starting
> >>> AND ending points. In [2] and [3], the ending point (and thus the
> >>> direction) is determined by the starting point. I see no
> inconsistency.
> >>
> >> This was brought up during the ftf, and I think it's a valid point.
> >>
> >> In my head (and I expect in others'), when I think of what angle to
> >> use for a gradient I do so by imagining a compass rose, with 0deg at
> >> the top, 90deg to the right, etc.  I then set the gradient angle by
> >> choosing which angle I want the gradient to point toward.
> >>
> >> Similarly, if I imagine keywords, I do so with 'top' at the top,
> 'right'
> >> at the right, etc.  Now, though, I have to reverse how I deal with my
> >> mental image - if I want the gradient to point up, I don't choose
> >> 'top', I choose 'bottom'.
> >>
> >> I'm not sure if this is an important enough disconnect to justify
> >> changing the keywords, but we brainstormed it a bit at the ftf.  I
> >> don't think we came up with any set of directional keywords that was
> >> sufficiently decent to work as replacements, though.  If anyone has
> >> any suggestions, please speak up!  The current front-runner is
> >> 'upward'/'rightward'/etc, which isn't very good.
> >
> > Right; to expand on some of the feedback given at the f2f, it helps to
> > think of animating or transitioning gradients in order to understand the
> disconnect.
> >
> > A safe - I think - working assumption is that CSS authors are very
> > familiar with top/right/bottom/left and the spatial relationship between
> them.
> Agree, and also the words used by border-radius to describe corners (top-
> right, top-left, bottom-right, bottom-left).
> > The
> > question is whether the following would be natural to web authors:
> > that transitioning a linear gradient from 0deg to 90deg is equivalent
> > on the keyword side to going from bottom to left.
> Would it be? Or would 'bottom left' (not necessarily 45deg) be the halfway
> point of that transition?

Not sure what you mean here.
> > In other words, given North==0deg and East==90deg,
> Is that a given now? Was it decided in Kyoto, without me there to voice my
> opposition? I haven't seen the transcripts yet. I still find it counter-
> intuitive.

That is  the resolution. Given the overwhelming feedback in favor of using
the same angle model everywhere I think the burden is on you to prove that
it is counter-intuitive for authors at large, not just yourself.

> It also means I can't use the prefixed gradients with degrees
> in live style sheets, even experimentally to gain author experience,
> because there will be no graceful degradation for those using slightly
> older browsers. And old versions only go away very slowly.

Sorry, but that is not and should not be a concern. CSS is unprefixed. 
Prefixed properties are experimental CSS. No more, no less.

We use  prefixes to prevent the spec from being locked by vendors
or web sites i.e. so that we do not have to be backward  compatible.

If you're using prefixed features in live stylesheets you have full
responsibility to handle all the consequences: differences between
browsers e.g. because browser X implemented Flexbox years ago vs.
six months ago (a real issue today), browser bugs which then get fixed 
and a new browser version implementing a newer version of a given spec. 

It seems to me your point demonstrates why one should be very careful 
about using *experimental* features on one's sites.

> Likewise, all of the many CSS gradient editors out there which produce a
> style sheet full of prefixed 'linear-gradient' and '-webkit-gradient' with
> degrees will have to be changed, and include a note about how the
> gradients will be completely different in slightly older browsers. And if
> we change the meaning of the keywords, then even more editors will need
> changing (including those with -ms-filter support, which only use keyword
> direction). In that case, IE6 would be supported, but existing versions of
> Firefox would not.

Same as above. Editors that rely on experimental implementations impose a
significant risk on their users. Ideally such editors would make their users
opt into using such features. I don't think we should lock a Working Draft
despite obvious quirks, issues and other inconsistencies because they do
> > should transitioning from
> > North to East be doable by transitioning from top to right ? I think
> > many would answer this question in the affirmative. (And would love to
> > see a poll on the question similar to the one done for the bearing angle
> issue).
> Maybe that would be a good question if we were using the keywords 'North'
> and 'East'. But we are not. Transitioning from 90deg (straight up) to left
> (meaning "from left to right") is perfectly reasonable.

This is rather baffling. You're saying here it is perfectly reasonable that
transitioning towards a keyword name 'left' from a position straight up should
map to 'from left to right' ? I'd wager a poll would find you in the minority
on this one as well.

> > That top is a starting point but 0deg an end point is inconsistent;
> > the inconsistency is hard to justify and even more confusing once
> animations are involved.
> Why is 0deg only an end point? The angle is the same along the entire
> path.

I don't understand what this means.

Received on Wednesday, 8 June 2011 18:52:29 UTC