Re: [css-variables] Remaining Issues

> 2. Any time a var() is used in a @keyframes rule, "taint" it.  Tainted
> variables can't be used in animation-* properties.

FWIW, I really like your tainting behavior proposal. This does not prevent 
the animation refactoring use case outlined before (unlike option 1) and 
it's reasonably easy to implement. However, I'm wondering whether it works. 
Wouldn't the style ends up oscillating between "valid animation-name, 
starting animation", "launching the animation, tainting custom vars" and 
"invalid animation-name using tainted custom var, dropping the animation". 
There may be a step missing somewhere in between, probably something like a 
CP value snapshot once an animation starts so that animation properties can 
keep using the property value before the animation started.




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

Yes and no. "#aaa" and "rgb(0,0,0)" can be inferred as colors. "red" and 
"transparent" can't, however.

I'm wondering if people would really want to update an <integer> in an 
animation, ie if it's not impossible to infer <number> by default and 
letting people set the <integer> type if necessary, which should almost 
never be the case.




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

Until the moment where you'll need to state it three times because you also 
want to use a type defined in CP-L3, fallback to a type defined in CP-L2, 
and no type at all for CP-L1 browsers :-)

The big advantage of type inference is that you get graceful degradation for 
free. CP-L3 will recognizes all types, CP-L2 will only recognize a few, 
CP-L1 will not recognize them.

Received on Thursday, 20 June 2013 18:02:12 UTC