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

On Jun 8, 2011, at 11:52 AM, Sylvain Galineau <> wrote:

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

I mean that perhaps a transition between two keywords might be different than a transition between their equivalent horizontal or vertical degree equivalents. A corner to corner transition is not 45degrees if the element is not square. Is 45deg the halfway point in a transition between 'bottom' and 'left', or is it 'bottom left'?

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

Well, how convenient that this resolution was passed at an oversees meeting where the change's staunchest and most vocal WG opponent couldn't make it. That must have made the decision pretty easy. 

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

The poll was presented without adequate arguments on the other side. Even so, several respondents shared my view, and many of those who voted otherwise were only mildly in favor of selecting the "heading" model. And some who found the more traditional model surprising also said they got used to it pretty quick. 

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

So you are basically saying "screw you" to any author that has used -*-linear-gradient for simple cases, or who wants to do so prior to CR, because we're going to change so much of it now that reasonable fallback is no longer possible. Usually, even with experimental features, an author can craft styles that get reasonably similar cross-UA results for UAs that implement the feature, and decent fallback in other UAs. This is different. With this change, we'll have major browser versions in which the fallback is to show horrible results. Even the major change we made to 'border-image' didn't do that. If we have such a major change to these gradients after they've had widespread adoption in the wild, even prefixed, then we should at least change the name to avoid being so destructive to existing 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
> not.

I'm obviously not above fixing problems and inconsistencies. But in the real world, people have already started using the simple, non-edge case parts they deemed consistent enough. And you want to punish them for that, and discourage ANY real world usage until CR? That is not the best way to get a stable spec. 

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

Maybe if you word it like that in order to sway the outcome. But anyone using the keyword 'left' knows that it means 'from left to right', or they find out within seconds and then move on. There is nothing baffling about transitioning between a value that means "straight up from the bottom to the top" to one that means "from left to right".

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

0deg indicates direction. Even if I only look at a tiny section of the gradient path, it is still 0deg. Both the start pount and the end point is determined by the direction, not just the end point. 

Received on Wednesday, 8 June 2011 22:50:46 UTC