RE: [css-variables] Remaining Issues

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

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.

I understand that my proposal has a cost, but it would be the following one: custom properties do not animate but all properties that reference a custom property modified in the keyframes are added dynamically to the keyframes and are animated independently. That solves the animation issue because the animation property is ignored in keyframes.

   @keyframes anim1 { from { var-anim: anim2; var-zoom: 1; } to { var-zoom: 2 } }
   selector { var-anim: anim1; animation-name: get(var-anim); transform: scale(get(var-zoom)); ... }
   
which translates to:

   @keyframes anim1 { from { animation-name: anim2; transform: scale(1); } to { transform: scale(2); } }
   selector { ... }

where animation-name inside the keyframes is ignored.

The only strange thing is that if a property is modified during the animation to include/not include a custom property, it would not be animated properly. But this is acceptable, since I learnt that animations work by "copying their state when they start" so it would just be one more thing being copied at the beginning.


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


>
> 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;
   }



Best regards,
François

Received on Tuesday, 11 June 2013 08:31:11 UTC