- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 12 Jun 2013 12:30:15 +0200
- To: François REMY <francois.remy.dev@outlook.com>
- Cc: Sylvain Galineau <galineau@adobe.com>, www-style list <www-style@w3.org>
On Tue, Jun 11, 2013 at 11:19 AM, François REMY <francois.remy.dev@outlook.com> wrote: >>> var-col-size: 33%; >>> var-col-index: 1; >>> position: absolute; >>> left: get(var-col-index * var-col-size); >> >> I don't see any 'replacement'; you're animating the left value in a way >> similar to what happens today when percentage values recompute as the >> width/height of a containing block is animated. > > If 'var-col-size' is not animatable, I can't animate 'left' anymore in a useful way. Or I've to loose the reason why we introduced variables in the first place: ie making internal value relationships visible. Let's rewrite the 'left' property into real syntax: left: calc(var(col-index) * var(col-size)); Okay, now, you can totally animate 'left'. Why would you think that the ability to animate 'left' is tied to the ability to animate 'var-col-size' in any way? If you change 'var-col-size' (say, to 20%), then the computed value of 'left' changes from "calc(1 * 33%)" to "calc(1 * 20%)", which is something that can be animated. > Also, the previous example where I split the 'transform' property into three subproperties (zoom, rotate, translate) that make more sense to me clearly shows that if I can't animate custom properties I can't use them freely. I think it makes sense to be able to do @keyframes { from { var-zoom: 1 } to { var-zoom: 2 } } instead of @keyframes { from { transform: scale(1.0) rotate(var(rotate)) translate(var(translate)) ... } because the latter cause cause duplication, and probably unexpected bugs. The latter does something completely different than the former. The former flips abruptly in value at 50% of the animation progress, the latter smoothly transitions throughout the animation. You're probably assuming that it's "obvious" how to animate that variables, because its value is just a number. It's not. Numbers can represent fractions or integers, which transition differently. More generally, the best we could try to do is match up the tokens in the stream 1-to-1 between the start and end values (maybe ignoring whitespace tokens), and if they match in types, assume that all number tokens and dimension tokens of the same unit just transition smoothly through real numbers, while everything else flips halfway through. This isn't a very good solution. A better solution is to prevent variable animation at this level, and allow it once they can be given type annotations. ~TJ
Received on Wednesday, 12 June 2013 10:31:01 UTC