Re: [web-animations] Should computedTiming return a live object?
On Sat, Oct 3, 2015 at 1:21 AM, Domenic Denicola wrote: > Anne's questions are interesting and worth answering. For example, which of > these properties are typically held in memory already, versus which would > require some kind of computation---the former usually are better as > properties, and the latter as methods. The timing properties are typically held in memory while the computedTiming properties will typically be generated on-demand since they can be calculated from the timing properties and some of them change on each frame.
Re: [web-animations] Should computedTiming return a live object?
On Sat, Oct 3, 2015 at 1:14 AM, Anne van Kesteren wrote: > On Thu, Oct 1, 2015 at 4:23 AM, Brian Birtles 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.
RE: [web-animations] Should computedTiming return a live object?
Anne's questions are interesting and worth answering. For example, which of these properties are typically held in memory already, versus which would require some kind of computation---the former usually are better as properties, and the latter as methods. But setting aside the deeper issues he alludes to, my gut instinct is that option 1 is pretty reasonable.
Re: [web-animations] Should computedTiming return a live object?
On Thu, Oct 1, 2015 at 4:23 AM, Brian Birtles 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. -- https://annevankesteren.nl/
