W3C home > Mailing lists > Public > www-style@w3.org > June 2013

Re: [css-variables] Remaining Issues

From: Ronald Mansveld <ronald.mansveld@gmail.com>
Date: Tue, 18 Jun 2013 22:35:04 +0200
Message-ID: <CAOscuh41s0+GeVNEhweqzfKS_3opu0Lm3gLc3z-P+o-guKbqpw@mail.gmail.com>
To: Lea Verou <lea@w3.org>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
On 18 June 2013 21:16, Lea Verou <lea@w3.org> wrote:

> On Jun 10, 2013, at 21:54, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> > There are three remaining issues on the Variables spec.
> >
> > 1. Animation behavior.  Should custom properties animate/transition
> > like normal properties (always being unrecognized, so they flip at 50%
> > progress), or not?  François pointed out that allowing them to be
> > animated can produce dependency loops in animations, where the
> > animation property itself uses a variable which it animates over.  I'm
> > thinking we should disallow animation/transition of custom properties
> > - they don't transition at all, and they're ignored in @keyframes
> > rules.
> I think it’s very useful to animate custom properties, since it allows
> somebody to have synchronized animations for different properties e.g. text
> color and border-color. I’ve actually needed this. So, I think it’s worth
> trying to find a solution to this rather than just disallowing animation
> for custom properties. Would it be technically possible to say that var()
> fetches the cascaded value of the custom property *ignoring* any animation
> on it? Or, to detect such cycles and render the declaration invalid?

I agree with Lea that animation of custom properties would indeed serve a
number of usecases (text + border-color, background + box-shadow color
among others). What if before the animation started the value of all
variables in the affected rules would be 'unpacked'? That way the code
running the animation has no pointers left to variables, but just to
primitive values, which automatically prevent circular
references/dependency loops.

Received on Tuesday, 18 June 2013 21:42:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:12 UTC