Re: Feedback on Web Animations

Hi Dean,

Thank you very much for this feedback. I agree with most of it. Other 
parts I've taken on board and proposed how we can address your concerns. 
However, some parts I don't think I've quite understood so please allow 
me to respond inline.

(2012/12/01 4:59), Dean Jackson wrote:
> A. No use cases.
> ================
>
> A major contributing factor to high-level concerns is that the proposal doesn't
> list any use cases, requirements, goals, hopes, dreams or ambitions. Instead,
> it jumps right into the technical details. This is a very large proposal (more
> on that below) - it's essential to list out the use cases so they can be
> prioritised.

This is one of the items on which I'd like some clarification. Do you 
mean you expect a list of use cases at the top of the spec? I notice, 
for example, that CSS Animations does not have such a list so I'm not 
sure why it is expected here.

There is some discussion of the motivations for the specification in the 
Introduction section (particularly the 'Relationship to other 
specifications' section). Would you prefer we extend this section? There 
have also been offers to write a primer. Would that help?

Alternatively we could add annotations to the interface members to 
describe the particular use cases where they are needed? These 
annotations would appear in the ED only. What do you think?

Of course, if the suggestion is that there really are no use cases, then 
we have documented a few general uses cases elsewhere[1]. In addition to 
those, other features are based on, for example, experience with 
Raphael, Mozilla bug reports, and the Parapara animation workshops.[2]

One particularly important use case (which admittedly is not documented 
anywhere) that has influenced the design is the desire to be able to 
debug animations. That is, it should be possible, using the API, to 
write a tool that produces a timeline view of all active animations (and 
in some cases past animations) in the document regardless of the markup 
used to create them. Would you prefer this sort of thing go in the 
introduction?

> B. Declarative Solutions.
> =========================
>
> We strongly think that any proposal for richer animations in HTML should be
> accompanied by a declarative form. It's nice that this proposal provides a
> powerful technology for scripting, but our primary audience should be people
> who write markup.

I strongly agree and, having discussed this with others this morning, 
everyone involved is on the same page. We're going to push hard to get 
the CSS spec moving along. The SVG spec will lag a little (simply due to 
limited personpower) but it should be easier.

> Timesheets are a pretty good solution to this. They can be easily linked from
> an HTML doc. They separate timing from content. They are easy to author. They
> support nested timelines, plus parallel and sequential timing. However, they
> are based on SMIL so could possibly be infected with the curse. Other options
> would be to create a new format (JSON, CSS- or HTML-based?) or propose changes
> to HTML directly.

I agree about timesheets as a concept.

We've discussed this in the group before and we want to support that 
style of usage. That is largely where the templates feature came from 
(which I'll address later).

SMIL timesheets themselves introduce other complexity that we don't 
think is necessary. Some of the ideas we've floated for combining CSS 
and SVG syntax (similar to Filter Effects) would give you the same result.

> This is also related to the simplicity request in section C below. Timesheets
> will not provide powerful interactive content, but neither did CSS Animations
> and it didn't hinder adoption. Being able to write a document that does things
> at particular times without going to script will likely be praised by the
> community. Think slideshows, presentations, tutorials, etc.

Making slideshows work without any script would mean you need 
declarative triggers. We've discussed adding that to the model but 
decided not to address it in version 1.

For now, the easiest route for achieving that would be to expose what is 
already available in SVG to HTML. If we can tidy up the SVG model and 
improve interop with CSS through this work then that might become a more 
attractive option.

(You can already target HTML with SVG animations in Gecko. If recent 
efforts to allow using SVG more directly in HTML come to fruition this 
becomes even simpler.)

> One very important use case to us is read-along in digital books - where words
> on the page are highlighted as an audio track speaks the story. EBook authors
> are not scripters. They need a fully declaritive solution, which ties to
> point D.1 below about separation of timing from animation. These elements are
> not animating as such, they are just changing state at particular times.

I've responded to this below.

> We realise that the proposal explicitly avoided declarative formats, suggesting
> that it forms the basis of a declarative technology, but we strongly believe
> the two need to be done at once. In fact, we think that a simple, author-
> friendly declarative format is more important to the Web than the API and
> should be a higher priority.

I agree about the importance of declarative approaches. I think of 
higher importance still is the underlying model. The API is just a way 
of expressing the model in concrete and testable terms and that is why 
we have described it first, not because we believe it is, of itself, 
more important.

> C. Overall size.
> ================
>
> This proposal is *WAY* too big for a 1.0 release. The supporting model is fine,
> but we object to exposing this much Web-facing API in a first release (again,
> without use cases, etc).

Firstly, by big are you primarily concerned about the number of 
features, or the number of interface members, or simply the length of 
the document?

Regarding the number of features, I agree. I am maintaining a list of 
features I'd like to drop from v1 and have already started removing some 
from the specification already.[3] Templates is on the list. More on 
that below. (Also, there are plenty of other requested features like 
adaptive duration and state machines that we deferred before even adding 
to the spec so we've been showing restraint along the way.)

Regarding the number of interface members, this is largely based on the 
debugger use case. We believe it should be possible to produce a 
timeline view of the animations in the document using only the API and 
that requires exposing certain state. Nevertheless I think it would be a 
useful exercise to go through each member and annotate it with the use 
case it is needed for and then see what we can drop. I've been doing 
that informally and added a few members to my list of items to drop 
mentioned above.[3]

Regarding the length of the document, we are trying to make explicit 
much of what is underspecified in SVG and CSS in a way that promotes 
interoperability. Our experience with developing a prototype polyfill 
for this specification shows the implementation size is modest.[4]

> And there isn't really a need for everything at once -- CSS Transitions were
> adopted extremely quickly compared to other Web features primarily because they
> were so small and simple. We should start small, with only the features that we
> think are absolutely necessary, and then iterate from there. To give an example
> from the proposal that isn't necessary in 1.0: templates. It seems hard to
> justify these as necessary. There are many other similar things that could be
> cut for now.

As I mentioned, templates is something I've proposed dropping as well. 
We discussed this at our meeting this morning and we may remove it from 
v1 after we've investigated it further.

Templates possibly seem quite unnecessary but they arose as a means of 
representing the relationship between markup and Animation objects. For 
example an <animate> element in SVG is not itself an Animation object 
but produces several Animation objects.

This interaction between markup and Animations becomes particularly 
important when you have complex markup such as timesheets.

By adding templates to the API:

- The interactions between markup and Animations/AnimationGroups can be 
defined in a way that is easily testable and is consistent between CSS 
and SVG.

- A similar interface can be used for modifying either the Animation or 
the markup thing that generated it, since, for example, both 
AnimationTemplates and Animations include a Timing object. Furthermore, 
the interface is the same for both CSS and SVG and hopefully much nicer 
than using the CSSOM or SVG's limited API.

So, that's the background for them, but they may not be necessary for v1.

> D.1 Separate timing from animation.
> -----------------------------------
>
> While this is partly true in the proposal, there needs to be a bigger
> separation of timing from animation. In other words, it should be possible to
> have elements controlled by time, rather than just move/animate over time.

I looked at adding another primitive specifically for this--i.e. an 
action that takes place at a given instant, as opposed to an effect that 
varies over time.

However, in the interests of keeping the API simple I realised that this 
can be easily achieved (and efficiently implemented) using a 
zero-duration animation.

For example, see the section on calculating the iteration duration. By 
setting sensible defaults (duration: 0, fillMode: forwards) it is 
possible to make an element fade out and then be set to display: none (a 
*very* common effect) by writing:

   new SeqGroup(
     [
       new Animation(elem, { opacity: '0%' }, 1),
       new Animation(elem, { display: 'none' })
     ]
   );

Likewise a simple property at a given time might be achieved as:

   // Display at time 3 seconds
   elem.animate({ display: 'block' }, null, 3);

(This extension to the Element interface has yet to be added to the spec 
but I expect we will have something like this.)

> For example, one could imagine a timed document that simply applied some CSS
> pseudo-class to elements when they were "active" (between their start and end
> times - not to be confused with the existing use of "active"). Then animations
> could be written in CSS, effectively giving a timing model to CSS.

The :time pseudo-class? [5] This is something that has informed our 
design.[6]

In the current model this can be realised with an AnimationFunction 
(possibly soon to become 'AnimationEffect') that sets the pseudo-class 
when the time fraction is non-null (call it CSSSelectorEffect?). It's 
simply up to the CSS integration to expose this through appropriate markup.

Of course, re-using Animation interfaces in such a way makes some of the 
timing parameters such as the easing function meaningless. If such a 
feature is exposed through CSS then I expect implementations will 
optimize for the case of an Animation using a CSSSelectorEffect by not 
sampling the effect unnecessarily within the active time span.

If you think this is problematic then I'm open to reconsidering adding 
primitives especially for these cases. For now I thought it best to keep 
the API simple.

> D.2 Media synchronisation.
> --------------------------
>
> The ability to synchronise any animation/timing to that of a media stream
> is essential. This is listed in the proposal but not clearly addressed.

Yes, it's very high on the todo list at the moment. There are notes 
concerning this on the agenda for the next meeting.[7]

> D. CSS Transitions.
> ===================
>
> It's not clear how CSS Transitions fit into the proposal. One of the most
> common requests we get is from developers who want to know what transitions are
> running, or whether a transition did run (the transitionend event is not enough
> because it doesn't fire when nothing happened).
>
> Both animations and transitions are conceptually "Animations", and share almost
> the same implementation in WebKit. However, it's likely that from a developer
> perspective Transitions are different enough that they should be covered by a
> separate specification.
>
> In other words, we think transitions are out of scope for this work.

I think saying, "it's likely that from a developer perspective 
Transitions are different enough that they should be covered by a 
separate specification" is not sufficient justification for ruling them 
out of scope.[8]

I think it would be better to attempt to try and write the spec 
expressing transitions in terms of the same model as animations and then 
consider if it makes sense or seems awkward.

As mentioned previously we hope it will be possible to write an 
animation debugger to view *all* animations in the document regardless 
of the markup used to generate them. If transitions were excluded, that 
would be surprising. Returning to your first point, does that count as a 
use case, requirement, goal, hope, dream or ambition?

Thanks again Dean.

Best regards,

Brian

[1] http://www.w3.org/Graphics/fx/wiki/Web_Animations/Use_cases
[2] http://parapara.mozlabs.jp/
[3] See https://etherpad.mozilla.org/ep/pad/view/MzLg1iUKv4/4sPNmceDjl, 
point 6, "The chopping block". Specifically, I removed 
TimingFuncCallback last week.
[4] https://github.com/shans/web-anim-js
[5] http://lists.w3.org/Archives/Public/www-style/2012Jul/0703.html
[6] http://lists.w3.org/Archives/Public/www-style/2012Aug/0148.html
[7] https://etherpad.mozilla.org/ep/pad/view/MzLg1iUKv4/4sPNmceDjl, point 3
[8] I've been working on some animation projects over the past year that 
incorporate CSS Animations, CSS Transitions and SVG Animations and I 
don't see transitions as belonging to a sufficiently different category.

Received on Tuesday, 4 December 2012 06:35:25 UTC