- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 19 Jun 2013 00:34:34 -0700
- To: Lea Verou <lea@w3.org>
- Cc: www-style list <www-style@w3.org>
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