W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2015

Re: [web-animations] Should computedTiming return a live object?

From: Brian Birtles <bbirtles@mozilla.com>
Date: Sun, 4 Oct 2015 11:39:51 +0900
Message-ID: <CAF-W_FT9n8+a==bZWM9Q4ay2THwdFvqZidMaDN8ngOd_e=CuoA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "public-fx@w3.org" <public-fx@w3.org>, "www-style@w3.org" <www-style@w3.org>, WebApps WG <public-webapps@w3.org>
On Sat, Oct 3, 2015 at 1:14 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Thu, Oct 1, 2015 at 4:23 AM, Brian Birtles <bbirtles@mozilla.com> wrote:
>> I'd like to change this API, probably to one of the following (listed
>> roughly in order of preference). I wonder if anyone else has an opinion
>> on this?
>
> I'm curious as to what this maps to closer to the metal. That can help
> inform a reasonable low-level API. The other thing I'm wondering about
> is whether it's still reasonably to introduce new synchronous layout
> getters/setters. I was hoping we'd move away from that at some point.

The timing part is conceptually equivalent to doing something like
elem.style.animationDuration = '3s' with the difference that we update
the internal value of the duration immediately, rather than waiting
for a style flush. It doesn't trigger synchronous layout however. It
simply queues a style update.

Fetching computedTiming will flush any pending style updates if it's
called on an Animation that corresponds to a CSS animation or
transition (i.e. not a script-generated animation) in much the same
way that calling getComputedStyle(elem).animationDuration does. It
doesn't invalidate style in anyway, however.
Received on Sunday, 4 October 2015 02:40:30 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 4 October 2015 02:40:30 UTC