Re: Feedback on Web Animations

I'm a likely end-user for declarative web animation.

I would welcome a simple timing mechanism or animation trigger system
to toggle a pseudoclass on given elements in time with audio or video.
I've spoken with colleagues who've expressed their desire for the
same, and I believe this feature would be well-received by the
community.

The idea of being able to direct animation with a timesheet -- linked
to a media element specifying timecodes as well as CSS selectors or
'actors' who would take the 'stage' at that time -- is exciting.
Staged elements could have the ':staged' pseudoclass applied so that
state and animation could be added with CSS.

I suspect that CSS animation triggers may form a separate
specification from the work being done on Web Animations, but I wanted
to voice my support for the concept here nevertheless.


Rationale and use cases
-----------------------
Currently, front end developers have to adopt JavaScript
implementations to sync simple CSS animations or state changes with
audio or video (examples follow). A CSS timing system could have a
range of applications that currently require JavaScript:

- Spoken website walkthroughs or 'talkthroughs'.
- Advancing presentation slides in time with audio.
- Read-along story books and web comics.
- Video subtitles and timed references where original video cannot be re-edited.
- Show notes in podcasts.
- Splash pages, product pitches, and anything that might benefit from
an element of interactivity and novelty that video alone can't
provide.

There are worse things than having to use JavaScript, but a CSS-based
solution would be welcome to simplify the workflow and to speed up the
perceived performance.


Existing declarative solutions
------------------------------
I've created a very simple JavaScript implementation of a CSS timing
mechanism called 'narrator.js' that uses a basic JSON timesheet to
toggle a 'staged' class on given elements at the denoted time:

http://nickcernis.github.com/narratorjs/

A very basic 'count to 20' demo showing a simple use case is here:

http://nickcernis.github.com/narratorjs/demo/

narrator.js fetches a JSON timesheet that the user creates to denote
which CSS selectors should be 'on stage' at a given time. These
'actors' have the 'staged' class applied to them during that time. The
staged class is removed if they are taken off the stage. This allows
simple state changes and animations to be applied with CSS at times
chosen by the user, where the timeline is linked to an audio element.
More information is available from the page listed above.

The consequence of this setup is that:

1. Timing is independent of animation.

2. Animation can be bound to a controlling media element (or, in
future, to the page itself) using HTML, CSS, and a simple timesheet.

3. Potentially, animation could be linked to other triggers instead of
'time'. The JSON timesheet could specify a list of nodes as a 'focus'
object that would trigger other elements to become staged as a user
tabs through a form, for example. Or the timesheet could be used to
track a given array of elements and make them 'staged' when they move
onto the screen as the user scrolls through a page. For this reason,
'timesheet' might not be a flexible enough name for future use cases
of CSS animation triggers.

Other solutions define the timesheet with JavaScript, such as
Mozilla's popcorn.js: http://popcornjs.org/popcorn-101

And some existing solutions use SMIL for timing:
https://github.com/aleross/timesheets.js


Summary
-------
Triggering animation based on a timeline linked to media elements or
the page itself has a wide range of potential applications.

I suggest the ':staged' pseudoclass to denote that an element is
currently being asked to perform. (Or perhaps ':onstage' or ':perform'
or similar, in case ':staged' implies that something was on stage but
isn't now).

There is an advantage in being able to specify cues using timesheets,
but any timesheet system should adopt a simple format to ensure a
shallow learning curve. SMIL is powerful, but perhaps too complicated
for wide adoption of simple timed animation.

A timesheet specified with JSON or CSS may prove to be popular, even
if this means omitting features such as chaining/parallel timing.

The option to trigger animation using the :staged pseudoclass based on
other triggers as well as time -- such as :hover, :focus, or other
psuedoqualities like whether an element is on screen or not -- may be
valuable in the future, and so 'timesheet' might be best avoided in
favour of 'directions', 'triggers', 'animation-script' or some
variant.

For many front end developers and use cases, a simple timesheet that
toggles state on given nodes based on time may prove to be sufficient,
even though SMIL and the current Web Animation proposals offer the
potential for much more complex animation than I have detailed above.

Nick Cernis

Received on Monday, 3 December 2012 22:34:29 UTC