Re: [css-variables] Remaining Issues

On Tue, Jun 18, 2013 at 12:16 PM, Lea Verou <lea@w3.org> wrote:
> 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?

While I agree in general that it would be useful to be able to animate
custom properties, they won't do what you want right now - animating
from "var-foo: red;" to "var-foo: blue;" will just flip the value from
"red" to "blue" halfway through the transition progress, rather than
doing a color fade, because there's no way to tell that it's supposed
to be a color.

I think the right solution is to disallow it entirely for now, and
think about this more when we introduce type annotations to custom
properties.

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

Use-cases are likely the same as the ones for using initial/default as
variable values.

Note that just invalidating a variable (like "var-foo:var(foo);") will
make it switch back to just inheriting its parent's value.  If we're
okay with just relying on that, we can treat all three as variable
values consistently.

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

Nah, we'd just do "var".  I'm fine with this.

~TJ

Received on Wednesday, 19 June 2013 07:35:22 UTC