Re: [css-round-display] Decision about if polar-angle turns into an angle or a keyword in the computed value

> On 08 Dec 2015, at 09:17, Brad Kemper <brad.kemper@gmail.com> wrote:
> 
> 
> 
>> On Dec 7, 2015, at 12:41 AM, Jihye Hong <jh.hong@lge.com> wrote:
>> 
>> Recently, the extension of the 2d rotation was added to the CSS Round
>> Display [1]. 
>> Keyword values, polar-angle and polar-angle-reverse can be the value for the
>> 2d rotate function. But it's not clear whether the keyword value turns into
>> an angle or remain as a keyword when determining the computed value of
>> transform.
>> 
>> If the keyword value remains as a keyword, you can't animate between it and
>> another angle value.
>> For example, animating between rotate: polar-angle and rotate: 0 isn't
>> possible.
>> However, when polar-angle property animates, the changes in it affect to
>> the rotation function with the keyword value.
>> 
>> If the keyword value turns into an angle, you can animate between it and a
>> different angle.
>> Thus you can animate between rotate: polar-angle and rotate: 0 or between
>> rotate: polar-angle and rotate: polar-angle-reverse.
>> But if polar-angle property animates, the rotation animation with the
>> keyword value will not track the changes in polar-angle property.
>> 
>> When suggesting polar-angle and polar-angle-reverse as keyword values for 2d
>> rotation transform function, the main goal of those value is to rotate the
>> element toward the origin point whatever the position of the element is in
>> polar coordinates.
>> 
>> Therefore, the keyword value should remain as a keyword at computed value
>> time.
>> Maybe there are some needs for animating between polar-angle and a different
>> angle, but I think tracking the changes in polar-angle property when
>> animating rotation function with polar-angle is more important than that
>> case.
> 
> I tend to agree. I can imagine a seconds pointer that bounces around the perimeter of a clock, by animating polar length and polar angle every second, where I'd always want it pointed outward. I can also imagine animating a number for the hours and/or minutes and/or seconds as it swept around the clock (you wouldn't then need static numbers displayed on the clock face), which would also be easier if I only had to animate 'polar-angle' and let the rotate angle take care of itself (while using JS to update the text itself every second). 
> 
> Animating between rotate(polar-angle) and rotate(0) could be nice too, occasionally, but much less important, in my opinion.

I agree about the priority between these two use-cases, but I am a bit confused about the mechanics.

If we say that rotate(polar-angle) computes to an actual angle at computed value time depending on the computed value of polar-angle, why does it not update to a new angle when polar-angle changes due to an animation?

And if it does, then computing to an actual angle rather than to a keyword seems to solve both animation around the clock face and animation from a specified angle.

The only case that seems a bit complicated is if you animate both polar-angle and transform simultaneously. For example from "polar-angle:45deg; transform:rotate(polar-angle)" to "polar-angle:90deg; transform: rotate(0deg)". In that case, we would be animating the transform from 45deg to 0deg, and the fact that polar-angle is simultaneously changing wouldn't affect that transform rotation's angle. But that seems fine to me. If you're animating both properties simultaneously, that's probably what you want anyway.

And if an author wants to take both into account, we could also enable calc and do things like that:
  @keyframes wooble {
    0% { transform:rotate(calc( polar-angle + 5deg ) ) }
    100% { transform:rotate(calc( polar-angle - 5deg) ) }
  }

  @keyframes round-the-clock {
    0% { polar-angle: 0 }
    100% { polar-angle: 360deg }
  }


>  It's a shame that we can't just animate the used values to do that, so that we could have our cake and eat it too, but it's the same situation with trying to animate from/to height:auto, I guess. 


That seems different, because you cannot resolve height:auto at computed value time.  But the rotate(polar-angle)'s relationship with the polar angle property *can* be done at computed value time.

Or can it not? Am I misunderstanding how computed values and animations interact?

 - Florian

Received on Tuesday, 8 December 2015 02:58:10 UTC