Re: [css-variables] Remaining Issues

On Wed, Jun 12, 2013 at 12:57 PM, François REMY
<francois.remy.dev@outlook.com> wrote:
>> 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.
>
>
> I fully agree with you. The problem is that you implied that "they're
> ignored in @keyframes rules" which means I cannot even
> change the value of var-col-size in an animation (in CSS).
>
> This is the only thing I was complaining about.

Right.  Animating 'var-col-size' is a no-go, but using a transition on
'left' is fine.

>> 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.
>
> Hum this is yet another & different problem: we're not speaking about
> whether custom properties are animatable, but rather how
> they transition.

That's the same problem.  You can't say something is animatable
without defining how it interpolates.

> I'm totally fine with letting this explicitely undefined in the L1 spec, I
> just didn't want the spec to say that custom properties are not animatable.
>
> The difference is that:
>
>   @keyframes { from { var-a: 1; } to { var-a: 2; } }
>
> switches from being ineffective to being effective but with no other
> guarantees that "var-a(t=from)" will equal "1" and "var-a(t=to)" will
> equal "2" which is closer to its final behavior.
>
> I expect browsers will actually switch the value at some point during
> the transition (my take would be at 0% between 'from' and 'to' but
> I've no major issue about this being at 50% between them).

Undefined is no good.  It's usually okay to change from "invalid" to
"valid" later, though.

> I think the wording of the animations specs is actually confusing here. The
> fact a property is animatable means it can transition, not that the
> transition has to be continuous (as far as I know). This is probably why we
> confused each other intentions. If your idea is just to specify
> they don't transition continuously for now, I'm fine with it. But they would
> still be animatable according to the spec.

Correct; Animations defines a number of value types which *do*
transition continuously, but everything else is defined to transition
with a single 50% step.

I guess I'm fine with defining that custom properties with no
annotation (all of them, right now) just fall into the default bucket.
 We just need to solve the animation problem.  Your solution is
reasonable, but complex.  Sebastian's solution (just disallow
animation-* from taking variables) is simple and, by just making the
use invalid for now, gives us wiggle room to solve it better in the
future.

(Note that Animations doesn't currently disallow the animation-*
properties from being animated, either.  This needs to be done,
obviously.)

~TJ

Received on Wednesday, 12 June 2013 11:24:51 UTC