- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Mon, 15 Aug 2011 10:06:56 -0700
- To: Alan Gresley <alan@css-class.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style@w3.org
On Aug 15, 2011, at 4:13 AM, Alan Gresley wrote: > On 12/08/2011 1:10 AM, Brad Kemper wrote: >> >> On Aug 11, 2011, at 6:21 AM, Alan Gresley wrote: >> >>> On 11/08/2011 12:21 PM, Tab Atkins Jr. wrote: > >>>> I don't understand the significance of the transform to this >>>> case. If you prefer using a keyword to indicate the starting >>>> point rather than the ending point, that seems independent of >>>> whether the element is being rotated by a transform. Is there >>>> something I'm missing, or is this just a statement that you >>>> prefer indicating the starting-point? >>> >>> >>> I prefer one step less when creating a gradient. Having just the >>> start value allows one less step. >>> >>> Step 1. Work out which way something is rotated. Since this may be >>> so deep via several rotations on child boxes, I have to get the >>> orientation right by placing a border on the box and then I give >>> the box a side border if I want to rotate, offset or provide a >>> margin to a side (sometimes this does not work since the edges of >>> the box are coming out on the z axis, so I start using my controls >>> [1]). >> >> If you are saying the gradient direction should be applied based on >> where you end up after a transformation, then I strongly disagree. > > > I'm not saying that at all. What I am staying is that I have created animations and not known where 'top', 'bottom', 'left' or 'right' are on certain elements. I may pick a side (what I can visually see) that I want an affect to begin/appear on but first I must know which side this is. To do this, I start adding borders. OK. I still don't know how that's relevant then. You implied that the keywords for gradient endpoints should be different because of transforms, but I don't see it, since the transform is something that is done after determining the endpoints. So I'm pretty confused by your argument. >> You shouldn't let the things you learned during an experimental phase >> prevent you from learning a revised syntax. If we waited until we had >> the perfect keywords that everyone could agree were the best, we'd >> still be arguing about it 5 years from now. We compromised, and >> settled for something good enough for most. When learning the syntax, >> some people will have a slightly harder time learning it one way and >> others will have a slightly harder time learning it the other way, >> but it is still easily learnable either way, and unambiguous this >> way. There seemed to be somewhat stronger feelings for picking a "to" >> direction for the model than for a "from" direction, so that won out >> in the compromise. > > > As I have mentioned before, gradients (nor any other background image) do not have a direction. I think most authors would have no trouble assigning directionality to a gradient line that connects corners, and saying it goes from one corner to another. It is harder, and less important, to understand why it must not be thought of in terms lacking direction. > Gradients are not compass bearings. Gradients can go from 0% to 100% and there is a path between these extreme points. The start of the gradient can theoretically be infinite and the ending can be infinite so theoretically the gradient is infinite in length. There is certainly an ordering in color stops but ordering is not a direction. > > Another reason that I see _direction to_ notation as wrong is that the syntax can not be extended in future and have it make sense. If it was possible to have the beginning of the gradient from 'top' and the end of the gradient to 'bottom right', > > -----T----- > | \ | > | \ | > | \ | > | \| > ---------BR > This type of syntax and gradient has already been considered and rejected, and the WG has made a resolution to compromise on the 'to' notation. Consider that probably 95% of gradient needs will be for horizontal or vertical gradients, maybe another 3% for angled (including corner-to-corner), and most of another 2% for radial gradients. The syntax should not be optimized or changed to something less simple in the future in order to be able to do what very few people would actually need to do. If someone really needs that sort of gradient and doesn't consider the 'deg' notation sufficient, they can always use SVG, I don't see that changing without strong author demand. > then having the 'to bottom' instead of 'top' complicate things. You could write this, > > _top to bottom right_ > > > where the reverse does not make sense. > > _to bottom from top left_ > > > and indicates a different vector. We have long ago agreed that it is enough to declare one corner or side and have the opposite corner or side be inferred. It is time to get over that and move on. >>>> Please read the "Gradient Magic" thread started a few weeks ago. >>>> It seems that the behavior described therein in manifestly better >>>> than the previously-described behavior for corner-to-corner >>>> gradients. >>> >>> >>> I didn't read that thread since I was on the verge of pneumonia but >>> regardless, I do like magic corners. >>> >>> What is happening is... >> >> Sorry, but I didn't really follow what you're trying to say here, or >> if there was something you didn't like about "magic corners". >> >> P.S. I hope we can eventually stop calling it that. There is nothing >> especially magical about picking the appropriate angle for connecting >> the corners. > > > Please take a look at the below code. This is what I mean by circumscribing a rectangle. The first color stop (red) is 30% down the gradient path and the last color stop (blue) is 70% down the gradient path. What happens when you transition from corner to side to corner. Do these color stops slide up and down the gradient path. As the code below now stands, the white midway line (perpendicular to the path) is situated on the 'top right' and the 'bottom left' of the rectangle but 'to bottom right' is suppose to indicate the rendering of this gradient. Are these gradients and transforms meant to simulate what is happening with the newer "magic corners" gradient? I'm a bit lost on what your point is now, if you are asking something about the code you included or on a model that it is simulating.
Received on Monday, 15 August 2011 17:07:29 UTC