- From: François REMY <francois.remy.dev@outlook.com>
- Date: Tue, 11 Jun 2013 16:56:46 +0200
- To: "Sylvain Galineau" <galineau@adobe.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: "www-style list" <www-style@w3.org>
> 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.
Received on Tuesday, 11 June 2013 14:57:13 UTC