Re: [css-variables] Remaining Issues

On Thu, Jun 20, 2013 at 1:37 AM, François REMY
<francois.remy.dev@outlook.com> wrote:
>> 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.

Hmm, I suppose you're right.

In that case, we still need to decide what the behavior is in:

@keyframes anim1 {
  from, to { var-foo: anim2; }
}
.foo {
  var-foo: anim1;
  animation: var(foo) 1s;
}

In that case, I think there are two reasonable solutions, one simple
but overkill, the other more complex but also more tightly targeted:

1. Disallow use of var() in animation-* properties altogether.  This
prevents the possibility of animation loops altogether.
2. Any time a var() is used in a @keyframes rule, "taint" it.  Tainted
variables can't be used in animation-* properties.

> (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,
> ...)

Some, yes.  Not all.  In particular, numbers can't be inferred (may be
a <number> or an <integer>), and colors *definitely* can't be
inferred.  I'd much rather have everything fail uniformly rather than
some of them working sometimes.

>    (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++)

I don't think it's worthwhile to require use of a type inference for
CSS variables.

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

SASS variables don't need to animate.  Everything SASS can do to a
variable, CSS can.

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

Graceful degradation is just stating your variables twice, once
without the annotation and once with.

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

Correct.

~TJ

Received on Thursday, 20 June 2013 17:39:37 UTC