Feedback on Web Animations

Here are some comments on the Web Animations proposal. They are high-level
because that's what we're most concerned with at the moment and we don't want
to distract the discussion with low-level comments.

In general we're supportive of the work, and think this does an excellent
job of explaining the animation model.


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.


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.

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.

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.

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.

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.


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).

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.

More supporting evidence for this approach is the failure of SMIL. The most
common complaint we heard about SMIL was that it was too big and complex. Yet,
the Web Animations proposal is recreating SMIL in JavaScript form. We suggest
that this will likely lead to the same result: lots of implementation effort
that is dismissed/ignored by the community.

Start small with the necessary features. Iterate. There is nothing wrong with
leaving functionality out.


D. API Design.
==============

It's hard to not go into specifics here, but the API needs more thought in the
design. This again could be related to the lack of use cases, or to the
modelling around existing technologies such as CSS Animations and SMIL. The
primary goal should be to have an API that people can understand, almost as if
they designed it themselves. We don't think that's the case at the moment.

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.

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.

It may be that there are two features here that deserve separate specifications.

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.


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.

Dean

Received on Friday, 30 November 2012 20:00:23 UTC