Re: [css-variables] Remaining Issues

> > 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.

I would not disagree with this, but we may actually want to be more 
flexible. A transition from '100px' to '200px' has only one way of being 
understood, I would prefer not to be forced to specify a type of this more 
than the one that is already implied by the value.

I feel compelled to design a more intelligent automatic continuous 
transition algorithm, that could be discussed for a possible inclusion in 
Level 2/3/n to replace the "flip at 50% behavior" in the most commonly used 
cases. This is why I proposed to use a more open wording like "While Custom 
Properties are animatable, the interpolation between two CP values is left 
willfully undefined in this specification. Meanwhile, it is recommended that 
the value of CP should be flipped when the transition function has a value 
higher than (0.5) unless some other specification define a more reasonable 
way to interpolate the two values." That looks sufficient to me to make sure 
we reach interoperability on Level 1 without closing the door to a smarter 
Level 2.

It also make sure that even L1 browser have, in most case, a reasonable 
approximation of animations built for L2 browsers.




> 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.

As I don't see any strong use case for defining animation names using 
variable (well, I see one but it's not so important), I think poisoning 
animation properties is a good solution. If use cases appear later, it can 
still be reverted in later revisions.

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

Good remark. In fact, not all animation properties are an issue, only 
animation-name is a problem (because the others are 'snapshopped' when the 
animation starts).

Received on Wednesday, 12 June 2013 11:42:58 UTC