Re: [css-variables] Remaining Issues



On 6/11/13 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. 

In the example you gave, no you can't. But that is just an example, not
really a clear use-case.

>Or I've to loose the reason why we introduced variables in the first
>place: ie making internal value relationships visible.
>
>
>> Intransigeant assertions are not very useful.
>
>Sorry, you're right.
>
>
>> Describing the kind of
>> use-cases that would be 'completely broken' adds much more value. The
>>one
>> you propose above seems unnecessarily contrived, fwiw. Animating the
>> addition of this column implies animating the width of the container,
>> which works today.
>
>Why? I could very well decide to split the same size into 4 columns where
>I previously had 3 of them. Or I could use an overflow to hide surnumeral
>boxes.

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.

> 
>
>By the way, the "animated" move from one column to the other don't seem
>like a very strange or border-line use case to me.

I did not say it was. The solution you proposed still seems contrived;
there are other ways to achieve the same thing without animating a
variable.

>That one clearly require the 'var-col-index' to be animated, if you don't
>want to know the value of 'var-col-size' in your keyframe. To make that
>clear, how can I have the same behavior as a @keyframe { from {
>var-col-index: 1; } to { var-col-index: 2 } }
I don't think anything is 'clearly' required until you go into more detail
and explain what you are trying to achieve. Until then we don't know
whether this is the only way to animate this element vs. say, animating
flex items.

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

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'. Author will keep doing what
they do today a little longer. Or maybe you have evidence this is a
frequent stumbling block?

>
>
>> You could then position your element using the right
>> property; this would be a lot simpler and require no calculation using
>> column index or column size.
>
>A example showing how you can create an animation which change the column
>to which an element belongs in a continuous way would be nice, provided
>you don't know how the column is sized a priori. With animated custom
>properties, it's as simple as @keyframe { from { var-col-index: 1; } to {
>var-col-index: 2 } }.

Received on Tuesday, 11 June 2013 10:13:12 UTC