Re: [css-variables] Remaining Issues

On Jun 10, 2013, at 21:54, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> There are three remaining issues on the Variables spec.
> 
> 1. Animation behavior.  Should custom properties animate/transition
> like normal properties (always being unrecognized, so they flip at 50%
> progress), or not?  François pointed out that allowing them to be
> animated can produce dependency loops in animations, where the
> animation property itself uses a variable which it animates over.  I'm
> thinking we should disallow animation/transition of custom properties
> - they don't transition at all, and they're ignored in @keyframes
> rules.
I think it’s very useful to animate custom properties, since it allows somebody to have synchronized animations for different properties e.g. text color and border-color. I’ve actually needed this. So, I think it’s worth trying to find a solution to this rather than just disallowing animation for custom properties. Would it be technically possible to say that var() fetches the cascaded value of the custom property *ignoring* any animation on it? Or, to detect such cycles and render the declaration invalid? 

> 2. How should the global keyword initial/inherit/default be treated?
> Are these more of a language-syntax feature, such that they should be
> obeyed when specified in custom properties, or are they more like
> normal values, such that they become the variable's value?  It seems
> like there may be use-cases for either.
Since these are properties, I think it makes sense to use `inherit` to inherit the value of the custom property on the parent rule, rather than use it verbatim as a value. I think there are quite a few use cases for that. What are the use cases for using `inherit` as a variable value?
Not sure about initial and default though. They’re pretty useless as custom property values and quite useful as variable values. However, it would be inconsistent to specify different behavior for inherit and different for initial/default :(

> 3. How does 'all' interact with custom properties?  Are they all reset
> as well?  If #2 is decided in favor of treating the keywords as normal
> variables values, how does that interact with this?
Agreed with fantasai, all should not reset variables. That's not why it was designed. If there are use cases for resetting variables, we could use something like var-all and disallow all as a permitted custom property name.

Cheers,
Lea

Received on Tuesday, 18 June 2013 19:16:57 UTC