Re: [css-variables] Remaining Issues

> Based on this thread, I think my conclusions are:
>
> 1. Disallow custom properties from being animated at this level.  When
> we add type annotations to custom properties, allow them to be
> animated at that point.  (We'll have to solve the "var-* in
> 'animation'" problem eventually, so this is just punting that for
> now.)
>
> Reasoning: Since we can't infer anything about the type of custom
> properties, we can't transition them smoothly, and I don't think that
> animating them with the "flip at 50%" behavior is very useful.  This
> also lets us have a solution now, so we have more time to think about
> how we want to solve the 'animation' loop issue.

I still disagree with this conclusion, and I think your reasoning has a few 
imprecisions that lead you to a suboptimal solution:



(1) The "flip at 50%" behavior is useful.
    (1.1) Even when you'll introduce typing, there will be cases where 
you'll want a 50% flipping.
    (1.2) Even if the transtion behavior isn't defined in level 1, flipping 
at key points does already provide a graceful degradation to browsers which 
do not support full transitioning on custom properties.
    (1.2) With 50% flipping, I can basically use a preprocessor to generate 
as many frames as deemed necessary to get a smooth transition using my own 
formulas for the interpolation instead of relying on the ua one.

Given the principle of progressive enhancement, I think we should
    - stick with animatable custom properties
    - keep the transition behavior undefined (only (t=0) and (t=1) are 
defined as the initial and specified values)
    - recommend flipping at 50% behavior if this transition is not ruled out 
by another spec

This garantees that CP-L1 browsers will not be completely unable to read 
animations using custom properties (graceful degradation, as in the case of 
red to green bouncing), and it also guarantees that we can use 
preprocessors/polyfills to generate the missing frames and therefore get an 
interoperable behavior across CP-L1 and CP-L2 browsers (the author has full 
control over the final quality).



(2) I disagree with the fact you can't infer anything about the type of CP 
from their value.
    (2.1) Most CSS values have a type which is uniquely decidable given 
their representation (100%, 50px, left, ...) or at least whose optimal 
transition behavior can be guessed, even if they are a few exceptions (red, 
5 vs 5.0, ...)
    (2.2) The current programming language trend is clearly towards type 
inference and automatic typing (OCaml/F# type system, 'var' in C#/TypeScript 
and even 'auto' in C++)
    (2.3) Preprocessors like SASS use variables for a long time, are very 
expressive, yet do no have explicit variable typing as far as I know.

Static typing of custom properties should stay a trick only used when 
everything else failled. Don't forget that CP-L1 browsers will ignore 
type-annotated CP so we will need clever mechanisms to make sure CP-L1 get a 
graceful degradation once we start using typing. I'd better resort on this 
kind of hacks only when it's really necessary, and I think those edge cases 
will have a very low probability.



BTW, I take this opportunity to note that I think we should mention that, 
since 'all: xxxx' does not cover custom properties, 'transition: all xxx' 
doesn't either.

Received on Thursday, 20 June 2013 08:38:17 UTC