> In the example you gave, no you can't. But that is just an example, not
> really a clear use-case.
Let me check something: do you really think that using custom properties as
an element in a formula is an edge use case? In my sense, that's the second
most important use case of property references after immediate constants
refactoring. If, to use a custom property as part of a formula, you've to
give up on animating the property properly, I don't see the point. Solving
the simple refactoring use case does not need any CSS spec, it's already
built-in in most preprocessors and it's easier to use than CSS custom
properties will ever be. What makes CSS property references worthwhile is
exactly that: they are dynamic at runtime. Giving up on this front seems
like a plan for weak adoption.
> Yes, you could do any number of things. The question is not what you could
> do, but why you would do it. Since the basic scenario you outline can be
> done in a far simpler fashion without requiring any custom property
> animation the burden is on you to describe a reasonable use-case where
> this is necessary.
I don't see how you can achieve my scenario using something else. As far as
I know, using flexbox or grid doesn't make it easy to switch the columns of
two objects *in a continuous way* i.e. like if I was moving the object using
a transform. The reason is that the localization properties of those layout
modes are discrete; I can set the column to 2, I can set the column to 1,
but the change will be instantaneous, there will be no time where the object
will be moving between columns 1 and 2. If I want to move an object
continuously I have to use transforms, and therefore have a way to refer to
the column width. Seems like what I'm trying to do with my 'var-col-size'
property. If you know a better way, please tell me so.
Also, you didn't comment on my other uses cases which are certainly in line
with what we should be able to do in CSS using custom properties.
I can clearly see a page-enter animation for animated comics for children
where a cartoon show a beautiful forest with butterflies and where the
shadows move from right to left (the var-shadow-angle animation use case) at
the same time the global ligthing is adjusted in a way that is supposed to
represent the sun moving to indicate the progress of the day, and then
finally the scene becoming dark to show it's the night and the beautiful
trees end up looking like unattractive monsters. You wouldn't want to have
to animate the shadows one by one, but animating two properties like
"var-shadow-angle" and "var-shadow-extent" would be pretty easy and should
provide good resuts with a simple formula.
The other use case, where you want to animate a color (like
var-player-color) on a buch of objects without knowing where they use this
color is clearly valid, too. Creating centralized modification points at
runtime for shared information accross declarations is the whole point of
CSS Custom Properties so this one use case is really a core use case of the
spec itself. If I can define a relationship between the colors of many
objects but not animate this color using CSS, what's the point?
> Yes, no doubt being able to animate variables would simplify this
> scenario. I would not, however, say the inability to do this *in Level 1*
> suggests Variables are 'completely broken'.
What has the correct behavior to do with a spec level? I don't talk about
adding features to the level 1 spec, I just talk about keeping the normal
module interactions instead of removing them.
I've been said once that some properties would not be animatable in
@keyframes by default because "someone could have left them in the keyframes
after noticing they didn't have any effect and suddenly switching them on
would break their site". If we say explicitely in the spec that CSS Custom
Properties are not animatable, it will become much harder to add the feature
back in further level. I prefer to have bugs in implementations according a
valid spec than features removed to help implementors claim they're
[css-variables-1] compilant.
> Author will keep doing what
> they do today a little longer. Or maybe you have evidence this is a
> frequent stumbling block?
What's the problem we're trying to solve here? I thought the use case of css
custom properties was to avoid code duplication, not make the problem worse.
All that being said, the method I proposed earlier in the thread is not
optimal in some cases. Therefore, I'll +1 on what Sebastian & fantasai said:
just make it impossible to use custom properties references (var(...)) in
'animation-name' for now. The others animation properties should not be a
problem since they are snapshotted before the animation begins.