(please see Advanced CSS Transitions & Animations Proposal for the proposal that this analysis discusses)
Recently, Google has provided a proposal for advanced CSS Transitions & Animations, which provides a great deal of declarative control over animations, to the extent of allowing the specification of complex declarative widget behaviors.
This document addresses two questions:
- can the behaviors suggested by this proposal easily be replicated with existing web technologies?
- if not, what's missing that would allow them to be?
- excss, which includes an in-browser CSS parser and rewrite mechanism.
- a parser/rewrite extension to excss that handles the grammar suggested in the proposal.
- a css event emulation library (to be released), which:
- determines when CSS changes have occurred and packages these changes up as events provided to callbacks; and
- allows the definition, setting, and tracking of novel properties that do not exist in CSS.
- a library that implements the behaviors suggested by the proposal.
Of these four components, the first two relate solely to interpreting a CSS-specific encoding of the animation state machines, and can therefore be safely ignored in this discussion.
Supporting the proposal
The third component detects changes in CSS state, where state can be:
- changes in the computed style applied to an element
- changes in the set of style rules that apply to an element
- changes in the values of properties set within a given style rule
In order to support the proposal as currently drafted, these changes need to be tracked - for example, if the computed style of an animated element changes, then that change might include a change in a state- property, which would trigger a state change.
The mechanisms of the proposal
- per-animation state graph storage - this is reasonably complicated as animations are defined piecemeal and need to be assembled based on the relative specificity of the selectors associated with each piece.
- per-animated-element instantaneous and animated state tracking - this is quite straightforward. Changes to state are triggered at this level by callbacks from the CSS event emulation library.
- @-webkit-keyframes declaration generation (for emulation of proposed from() and to() functions) - this is pretty simple
- shortest path calculation for state graphs - this isn't precisely simple, but follows a well-known algorithm (Dijkstra's algorithm for shortest paths)
- conversion of shorthand to longhand for CSS properties - this is only partially implemented, and is needed because of WebKit's computedStyle behaviour (it provides only longhand values, which means that animations specified as shorthand need to be converted to longhand before from() and to() functions can be correctly emulated).
This isn't a small library, but much of it could be removed if:
- relative keyframes (from(), to() and prev() functions) were implemented by the web platform - this would remove both the declaration generation code and the need to convert shorthand to longhand.
- the CSS declarative syntax were abandoned and state machines were only generated procedurally - this would remove the need to build up state machines from rules associated with selectors of various specificities.
The result would be a library that tracked state machine structures and per-element state, and that applied pre-existing keyframes definitions to elements based on the differences between current animated state and instantaneous state for each of these elements. Instantaneous state changes would be generated by function calls, which would need to be manually hooked up to event callbacks.
In order to fully match the proposal, support for animation blending also needs to be implemented, however again this could be provided by the web platform as it's a generally useful feature.
With the following features baked into the web platform:
- some form of CSS events mechanism
- relative keyframes (from(), to(), prev() functions)
- animation blending