Re: [css-variables] Remaining Issues

On Thu, Jun 20, 2013 at 2:15 PM, François REMY
<francois.remy.dev@outlook.com> wrote:
>> The tainting is a "compile-time" operation - even if you never use the
>> @keyframes, it'll still taint any variables in it.
>
> Ok, seems about good then.

Ok, so the proposal is:

Scan any @keyframes rules for var-* properties being animated.  Taint
their associated variables - any use of var(*) with the same name in
an animation-* property produces an invalid variable.  Aside from
this, custom properties animate/transition like any other property
without a predefined interpolation behavior.

I don't think that's too hard.  We'll discuss this at the next telcon.


>> 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.
>
> That's probably a mistake since we use url(#id) everywhere else, but let's
> suppose that it ends up being implemented that way. Would you want to
> animate this property? Via a custom property? Better question: how more
> likely are you to animate this than you're to animate over a color? (and
> what's the probability you'll want to animate from a color-like ID to
> another color-like ID?)
>
> I don't say we don't want static typing, I just say we should provide
> reasonable defaults so that people do not have to use static typing at least
> 95% of the times. The remaining 5% will need static typing, and that's okay.
>
>> This isn't really inference, though.  It's guessing, and it's not
>> reliable.
>
> True. I'm always in favor of guesses that can get very reliable if the
> author can override them, but I agree it's a personal preference. Anyway,
> this is all about L2+ stuff, we'll have much more time to discuss this and
> see what we can do/can't do in the coming years. It's not an issue anybody
> has for Level 1. If basic flip-animatability is on the table, that's all
> right.

Right.

~TJ

Received on Thursday, 20 June 2013 23:31:30 UTC