Re: [css3-images] gradients keywords and logical (Re: [CSSWG] Minutes and Resolutions Telecon 2011-08-10)

On Aug 11, 2011, at 6:21 AM, Alan Gresley wrote:

> On 11/08/2011 12:21 PM, Tab Atkins Jr. wrote:
>> On Wed, Aug 10, 2011 at 6:48 PM, Alan Gresley<alan@css-class.com>  wrote:
>>> If I have this markup,
>>> 
>>>  <div><div>...</div></div>
>>> 
>>> and this CSS.
>>> 
>>>  div div {
>>>    transform: rotate(45deg);
>>>    transform-origin: top left;
>>>    background: linear-gradient(keyword keyword, white, blue);
>>>  }
>>> 
>>> On the rotated inner box, I want the gradient going from corner to corner
>>> beginning from the visual left with white and ending on the visual right
>>> with blue. I would expect to use these keywords.
>>> 
>>>  (since I already have _transform-origin: top left_).
>>> 
>>>    background: linear-gradient(bottom left, white, blue);
>>> 
>>> and not this.
>>> 
>>>    background: linear-gradient(to top right, white, blue);
>> 
>> 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 don't think most people are going to need to know which way something is rotated in order to decide which direction the gradient should go.  It is often a background of a box with some text in it, and the gradient will need to remain at the same angle relative to the text, not relative to the transform. This is how it is for every other background-image, including repeated raster images used in legacy browsers to get a gradient effect. I do not want to look at something that has gone through several transformations and is now rotated 51.673deg, and then try to figure out which direction to use now in order to get the direction relative to before the transform. And I always want to know what it is before the transformations, so that the background images rotate right along with everything else in the element.

> (now if I can just use the keyword for the start position, then I go no further)
> 
> 2. If I had a top border, I now think opposite of the side of the border which is 'bottom' and remember to include 'to' to have 'to bottom'.

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.

If we only stuck with what people had learned already from experimental versions, we'd be saddled with the earlier and horrible '-webkit-gradient' syntax (no offense, Apple).

>>>> TabAtkins: They're still equivalent
>>>> TabAtkins: It's just a different angle computation
>>> 
>>> Can you please explain this Tab? Can you please explain why current prefixed
>>> behavior should change for keywords?
>> 
>> 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.

>>> You seem to have some mental model but more details will appear in
>>> css4-images.
>> 
>> Sorry, this was a little clearer in the call.
>> 
>> The idea is that an animation is rendered by referencing the start and
>> end state and the current completion percentage.  If the size of the
>> box changes, such that the start or end states would have been
>> different, the animation is changed accordingly at the next update.
>> 
>> This isn't specific to gradients; it's a general issue with
>> animations.  Run this example to see the effect in action:
>> 
>> <!DOCTYPE html>
>> <style>
>> div { height: 30px; }
>> #foo { -webkit-transition: width 1s linear; width: 50%; background: green;}
>> #bar { -webkit-transition: width 2s linear; width: 50%; background: blue;}
>> #foo:hover { width: 90%; }
>> #foo:hover>  #bar { width: 10%; }
>> </style>
>> <div id=foo><div id=bar></div></div>
> 
> 
> OK, good, good but can you please explain what you are seeing in your head? I do not have access to your head and since it may be filled with crack, it maybe unwise to have such access. I still don't understand why gradient keywords referencing the start point are confusing to you. Anyway, I can live with whatever is decided in regards to these keywords.

Tab is not against using the keywords, even if he started out a little reluctant sounding. This is probably the first time we used two of them together like this, I think, and it does sound a little odd to me to say (in English) "to after start" or "to before end". But that shouldn't dissuade us from using these keywords that we use elsewhere, as the use cases are strong using them in gradients.

Received on Thursday, 11 August 2011 15:11:26 UTC