Re: [css-variables] Remaining Issues

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

The tainting is a "compile-time" operation - even if you never use the
@keyframes, it'll still taint any variables in it.  This has some
false-positive potential, but only if you're punning on variables,
using the same variable name for a column-size in one place and an
animation-name in another.  (Since keyframes are global, this could
result in problems if you're *accidentally* punning with a widget's
styles, but I think that's low enough chance to not care too much.)

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

Nope, still can't.  #aaa might be an id selector, for example.  We use
naked id selectors in at least one property, in CSS UI.

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

Given that using a non-integer <number> in a property that expects
<integer> invalidates the property, I definitely think people would
care.  For example, you might be using a variable for z-index.

>> 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 :-)

Likely we'll add fallback directly to the type annotation syntax. ^_^

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

This isn't really inference, though.  It's guessing, and it's not reliable.

~TJ

Received on Thursday, 20 June 2013 20:15:17 UTC