W3C home > Mailing lists > Public > www-style@w3.org > June 2013

Re: [css-variables] Remaining Issues

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 12 Jun 2013 12:30:15 +0200
Message-ID: <CAAWBYDAzZtMa_Vs8z4=ER0_eobhJLeSz_t5yCcMXHbrWfBYQgQ@mail.gmail.com>
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.

Received on Wednesday, 12 June 2013 10:31:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:31 UTC