W3C home > Mailing lists > Public > public-fx@w3.org > July to September 2012

Re: [web-anim] API feedback (was: [css3-animations] time sources, videos and storyboards)

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 3 Aug 2012 08:19:32 -0700
Message-ID: <CAAWBYDAkbZdPeKAO42iq_Vy5QjTeOmNWrPVxzfOdss3KpzfSOQ@mail.gmail.com>
To: Fran├žois REMY <fremycompany_pub@yahoo.fr>
Cc: Brian Birtles <bbirtles@mozilla.com>, public-fx@w3.org
On Fri, Aug 3, 2012 at 1:06 AM, Fran├žois REMY <fremycompany_pub@yahoo.fr> wrote:
> |  From: Brian Birtles
> |
> |  Lately we've been discussing getting rid of liveness altogether. It's
> |  mostly required for CSS and SVG and I've been suggesting that CSS and
> |  SVG will already be doing their own bookkeeping so they can implement
> |  the liveness behaviour they require (e.g. reflecting changes to
> |  properties/attributes across to all animation instances).
> This is putting much burden on the other working groups to have this
> correctly defined. Since the use case is valid and spread accross CSS and
> SVG, liveness should probably be implemented somehow in the WebAnimation
> layer.

This actually isn't burdensome at all, particularly since we'll be
defining the CSS and SVG mappings on WebAnimation anyway, so there's
nothing for the other groups to do.  ^_^

> |  > (in order to add animations / video playback synchronization)
> |  > In [[6.5 The TimedItem interface]] section, I think we should refactor
> |  > part of the TimedItem interface into a TimeSource interface.
> |
> |  Ok, I have to think about this a bit more.
> |
> |  The current plan with regards to media groups is outlined in point 4,
> |  here: https://etherpad.mozilla.org/lIwpKlVNd2
> |
> |  The time source idea is growing on me. It's a little more invasive (in
> |  HTML) than what is on the etherpad but HTMLObjectElement.timeSource is
> |  more intuitive than HTMLObjectElement.timedItem.
> Actually, the element itself can be the timeSource, if it implements the
> interface. I initially made the interface based on what is already implement
> on all HTML media elements. This would be a no-op to implement a
> such-defined TimeSource interface on them because everything is already
> there. Granted, using a property to expose an external TimeSource instance
> is also posible.

Yeah, not sure why I didn't think of that during the meeting.  We
don't actually need any multiple inheritance - we just have to define
that the functions that want a TimedItem instead want a (TimedItem or
HTMLVideoElement or ...)  (or, better, define a typedef for this, so
updates only require a single change).

Received on Friday, 3 August 2012 15:20:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:48 UTC