Re: [css-variables] Remaining Issues

On Tue, Jun 11, 2013 at 10:30 AM, François REMY
<francois.remy.dev@outlook.com> wrote:
>>
>> 1. Animation behavior.
>>
>
> My take on this is still that we should allow custom properties to be animated, or we'll lose a very important aspect of custom properties, ie their possibility to replace normal properties.
>
> My example will be the [css-variables]'s workaround to the lack of multivalued properties:
>
>    #some { transform: get(var-zoom) get(var-rotate) get(var-translate) }
>    // now I want to animate them...

Seriously, please stop using your custom syntax.  It's not happening,
and it just distracts from your examples.

Anyway, if you were to animate 'var-zoom' (perhaps from "scale(1)" to
"scale(2)"), it wouldn't do what you wanted - it would just jump from
its initial value to its final value halfway through the transition.
We have no reasonable way of interpreting a custom property value in a
way that allows it to be smartly transitioned.

(I plan, in level 2, to look into ways of adding type annotations to a
variable.  This would give the necessary information to make it
animatable.)

> So, the question is: how to solve the problem of properties whose value has an impact on the other properties. My guess is that we should replicate how it works now: if I try to animate the 'animation' property in a keyframe, it has no effect. When you reference a custom property inside an animation property, you transform it into a long-hand of the animation and therefore make it totally not animatable.

So we track the variables used in any animation-* (and transition-* ?)
properties, and make them non-animatable?


>> How should the global keyword initial/inherit/default be treated?
>
> To me, this issue is solved by way those keywords are defined. They apply at computation time, and variable replacement happen before that (I call this resolution time). So, they have no effect on custom properties. All of them can be simulated using special references (get(parent var-...), get(undefined), ...) so we don't remove any possibility by doing so.

I agree that appealing to the way they're defined is nice, but you
don't have their definitions correct.  The global keywords are all
handled at specified-value time, not computed-value time.  Variables
aren't substituted until computed-value time.

>> How does 'all' interact with custom properties?
>
> I'm not sure about that one. My guess is that custom properties are like expandos and don't obey to normal super properties. My option would be: let's define a "var" property whose value is used as the default value of all custom properties not defined on the element.
>
>    {
>       var: get(undefined); // don't inherit any variable;
>       var-xyz: blue;       // define one property;
>    }

Yeah, this is what fantasai suggested.  I'm probably okay with this.

~TJ

Received on Wednesday, 12 June 2013 10:22:25 UTC