- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Sun, 4 Oct 2015 11:39:51 +0900
- 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