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

[Brian Birtles]

On Sat, Oct 3, 2015 at 1:14 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
> On Thu, Oct 1, 2015 at 4:23 AM, Brian Birtles <bbirt...@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.

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

[Brian Birtles]

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.

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

[Brian Birtles]

(CC-ing public-webapps and www-style since I think this API needs more
eyes on it)

Hi,

Web Animations currently has the following API[1]:

 interface AnimationEffectReadOnly {
 readonly attribute AnimationEffectTimingReadOnly timing;
 readonly attribute ComputedTimingProperties  computedTiming;
 };

 interface AnimationEffectTimingReadOnly {
 readonly attribute double delay;
 readonly attribute unrestricted doubleiterations;
 readonly attribute (unrestricted double or DOMString) duration;
 // etc.
 };

 dictionary AnimationEffectTimingProperties {
 double delay = 0.0;
 unrestricted doubleiterations = 1.0;
 (unrestricted double or DOMString) duration = "auto";
 // etc.
 };

 dictionary ComputedTimingProperties : AnimationEffectTimingProperties {
 unrestricted double endTime;
 unrestricted double activeDuration;
 double? localTime;
 // etc.
 };

Basically, in AnimationEffectReadOnly, 'timing' points to a live object
but 'computedTiming' points to a dictionary.

Now, attributes can't use dictionary types but this was added because we
were under the impression that this would become possible in the future
similar to the way arrays can now be used using FrozenArray.

However, having thought about this more and discussed with Cameron,
this is probably not a good API in a lot of ways. For a start, having
'timing' return a live object and 'computedTiming' return a snapshot is
odd.

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?


OPTION 1. getComputedTiming()
-

i.e. continue to return a dictionary but make it obvious it's not live.
Having 'timing' and 'getComputedTiming()' is a bit weird but the only
concrete subclass(es) of AnimationEffectReadOnly is
KeyframeEffect(ReadOnly) which has 'getFrames()' so this naming is
consistent.


OPTION 2. Replace ComputedTimingProperties with a live interface


i.e.

  interface ComputedTimingReadOnly : AnimationEffectReadOnly {
  readonly attribute unrestricted double  endTime;
  readonly attribute unrestricted double  activeDuration;
  readonly attribute double?  localTime;
  // etc.
  };

This is probably easier for authors since they can just type
'effect.computedTiming.localTime' instead of
'effect.getComputedTiming().localTime' but I think we're trying to keep
away from these kind of live objects that depend on others based on our
experience with the SVG API. (Once these interfaces get constructors you
end up having to implement an 'orphaned mode' and a 'tied to this other
object mode' and it's all quite messy.)


OPTION 3. getComputedTiming(), getTiming(), setTiming()
---

If live objects are bad and inconsistency is bad, then maybe we should
rework the 'timing' member too and make it set and get dictionary
objects. The tricky part is when you want to update just a single timing
property. We'd probably need to either drop the dictionary defaults or
provide some means for doing 'effect.setTiming({ iterations: 2 })'.

Also, I think the fact that 'computed timing' is read-only while
'timing' is writeable justifies them being different (method vs
attribute).


There are other options too but the above the main ones I'm considering,
especially option 1.

If anyone has any suggestions, please let me know.

Best regards,

Brian

[1] 
http://w3c.github.io/web-animations/#the-animationeffectreadonly-interface

Re: template namespace attribute proposal

[Brian Birtles]

On 2015/03/14 9:41, Karl Dubost wrote:

Tab,


The only conflicts in the namespaces are font
(deprecated in SVG2), script and style (harmonizing with HTML so
there's no difference), and a (attempting to harmonize API surface).


*If* I didn't make any mistakes
(I quickly did and didn't check everything.)

The intersection seems to be:
['a', 'style', 'script', 'track', 'title', 'canvas', 'source', 'video', 
'iframe', 'audio', 'font']


'track', 'canvas', 'source', 'video', 'iframe', and  'audio' will be 
removed from the SVG2 spec (and SVG namespace). We want to allow them 
directly in SVG but using HTML namespace.[1]


'font' is obsolete.

('image' might be another conflict since HTML autocorrects image to 
img for compatibility reasons[1] but perhaps we could let image 
refer to the SVG image in this context?)


[1] http://www.w3.org/2015/02/11-svg-minutes.html#item05
[2] https://html.spec.whatwg.org/multipage/syntax.html#parsing-main-inbody