How to approach this will depend a bit on how successful bug 999922 is, but if possible I'd like to make these share an AnimationSet for each of element/:before/:after Rationale: * We want to be able to say, "Get me all the animations (including transitions) for this element" -- The list might be filtered (e.g. only those destined for the compositor, only those currently running etc.) * Later we need to be able to represent animations generated using the Web Animations API and SVG animations. Having four different managers with four separate lists is quite cumbersome. * Having a single array would simplify a lot of operations (e.g. HasAnimationForProperty could be done generically once) * For non-CSS animations we have to resolve which animation wins when several are competing (and once we support animation addition we have to resolve the order of addition) so we'll need to sort the array of animations. If we can store all animations in a single set we can keep them sorted rather than sorting on every sample -- For operations that are limited to, e.g. transitions only, we could maintain a separate array in the appropriate manager. I'm not sure what would be the most suitable data structure to make maintaining the two arrays fast and robust. -- Maintaining a separate array could possibly simplify special-case sentinel handling---we could possibly keep sentinels in the transition manager's array only. Not sure about this. At any rate there is a fair bit of code in these classes that is sufficiently similar that it could be merged.

Some background research comparing FlushAnimations with FlushTransitions: FlushAnimations Gets time For element/:before/:after Works out if it can throttle (asks ElementAnimations and compares with flag) Calls EnsureStyleRuleFor Calls CheckNeedRefresh If style rule has changed posts restyle Sets need style flush if it throttled Dispatches events FlushTransitions Early return if mElementData is empty (why doesn't FlushAnimations do this? Because pending events can be populated already that we need to dispatch?) Gets time For element/:before/:after Works out if it can throttle (asks ElementTransitions --- same as FlushAnimations) // Started/finished handling Goes through each transition Clears out sentinels on throttleable ticks If the transition has finished Creates transition end event Marks the transition as a sentinel Updates animation generation Sets started/ended flag Otherwise if we could throttle and have a transition that should have started on the compositor: Updates animation generation Sets started/ended flag If we can't throttle or started/ended is set, posts restyle Destroys ElementTransitions if it has no transitions Sets need style flush if it throttled Dispatches events DOESN'T call EnsureStyleRuleFor What does? nsTransitionManager::WalkTransitionRule (called by RulesMatching) CommonAnimationManager::UpdateThrottledStyle