W3C home > Mailing lists > Public > www-style@w3.org > June 2011

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

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Thu, 9 Jun 2011 00:25:36 +0000
To: Brad Kemper <brad.kemper@gmail.com>
CC: Tab Atkins Jr. <jackalmage@gmail.com>, Brian Manthos <brianman@microsoft.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <3C4041FF83E1E04A986B6DC50F017829031A7C@TK5EX14MBXC297.redmond.corp.microsoft.com>
[Brad Kemper:] 
> On Jun 8, 2011, at 11:52 AM, Sylvain Galineau <sylvaing@microsoft.com>
> wrote:
> 
> >
> > [Brad Kemper:]
> >> On Jun 8, 2011, at 9:59 AM, Sylvain Galineau <sylvaing@microsoft.com>
> >> wrote:
> >>
> >>>
> >>>
> >>> [Tab Atkins:]
> >>>> On Wed, Jun 8, 2011 at 4:27 AM, Brad Kemper <brad.kemper@gmail.com>
> >> wrote:
> >>>>> On Jun 7, 2011, at 11:34 AM, Brian Manthos
> >>>>> <brianman@microsoft.com>
> >>>> 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.

I don't think it's strictly necessary to assign motives. But if you must
insist, that only one member of a large WG is really opposed to something does
somewhat facilitate a final resolution, yes. And you may certainly object
to said 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.
> 
> The CSS.info poll was presented without adequate arguments on the other
> side. 

I disagree. I don't think it made a case either way. That the bearing angle
matches what 2D Transforms and SVG support is not only factual but perfectly
relevant, for instance.

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

That was certainly not a majority opinion. That people are used to what they
have could be used by anyone to argue against almost any change. 

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

Again, it isn't strictly necessary to assign overly negative motives or 
language to make your point. Fallback for experimental vendor-specific
implementations is up to each vendor e.g. WebKit could well decide to
keep their -webkit implementation as is and wait for the unprefixed
property to implement the new model. If the current implementation really
is widely used, that seems perfectly reasonable to me. The WG defines
the proper behavior of the unprefixed property. What the prefixed
version actually does is up to each vendor.


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

What part of 'use experimental features at your own risk' is unclear ? Those
people who used WebKit and Gecko's original incompatible implementations of 
the feature have also been 'screwed', to use your characterization. The only
difference between those users and the current ones, presumably, is the
existence and status of a document on w3.org and their number ? 

That the process was smoother in other cases is great, but it is not a rule
afaik. And, imo, should not be. At the very least, arguing about 'breaking 
the web' should be done with actual evidence of the impact as opposed to
assertions it is too large.

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

I expect people to be responsible and accountable for their own choices so
that this WG does not get 'punished' into standardizing suboptimal designs
or even bugs because an ill-defined number of people have opted to use one 
or two *experimental* implementations of a *draft*. 

At the very least, I find it disturbing that a new draft should use a model
incompatible with other existing, implemented specs because some amount of 
content has been authored using experimental implementations of said new draft. 
It implies that those authors who use something first get to 'vote with their 
site' and lock feature evolution. I guess it could be natural for you to see it 
as a clear improvement over vendor first-mover advantage since you're one of 
those well-informed early adopters but I'd rather avoid both.

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

To be honest, this is your response about most feedback you disagree with 
lately so it's getting harder to read it as more than a rhetorical dismissal. 
Especially when you also use the kind of tone you employ above. 

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

I don't agree that going from North to East intuitively maps to 'bottom to
left' (vs. top to right). Or that from the top of the compass to a keyword called 
'left' clearly means 'clockwise from noon'. I fully admit I don't quite know how 
to justify why something is natural to me but that should be no surprise :) It
seems to me you and I are in the same boat. Just acknowledge that a) what is 
natural to you is not to others b) their viewpoint may be both reasonable and 
legitimate, with no form of ill-intent or intentional 'swaying' of wording. And 
let's take it from there.

> >
> >>> 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.
 
Why shouldn't top mean 'towards the top' and right 'towards the right' so
that transitioning from top to right is equivalent to going from 0deg to 90deg
on a bearing compass ? That seems perfectly coherent to me. 

Let me guess: if I phrase this way, I'm swaying the outcome ? :)
Received on Thursday, 9 June 2011 00:26:07 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:41 GMT