Accordion: Activating a panel during animation fails

Accordion's clickHandler() ignores animation requests if an animation is already in progress:

// if animations are still active, or the active header is
// the target, ignore click
if (options.running || (options.alwaysOpen && clickedActive)) {
  return false;
}

Unfortunately, this logic leads to very unintuitive behavior and perceived brokenness. Worse, since accordion("activate",...) is built atop clickHandler(), even programmatic requests to expand/collapse an item will be ignored if an animation is already active, thus accordion's state and response to programmatic actions essentially is indeterminate.

The problem manifests most obviously when the event option is set to "mouseover". Under the "mouseover" configuration, the widget behaves in a perceived ''broken'' fashion from both the user's and programmer's standpoint as described below.

• If the user moves the mouse fast enough across the face of the accordion, events which should open items underneath the mouse are ignored. With accordion's default (hard-coded) ''slow'' durations, this issue manifests frequently, with even moderate speed of mouse movement. The result is that, when animation completes, the mouse very often is hovering over an unopened item (because the mouse's entry into the item was ignored). To the user, this is perceived as broken behavior since an accordion should always open the item over which the mouse is hovering.

• I have a case where I need the accordion to revert to its original state if the mouse leaves the accordion's bounds. To accomplish this, I bind to "mouseleave" and have it invoke accordion("activate",...) in order to restore state. Unfortunately, since activation is built atop clickHandler(), the activation request often is ignored since animation frequently is in progress as the mouse leaves the accordion's bounds. Not only does this make the accordion's behavior inconsistent from the user's perspective, but it also makes it impossible to set the accordion to a known state programmatically.

Rather than ignoring new animation requests if animation already is in progress, there are better, more intuitive approaches. Some possibilities include:

• Jump the current animation to its end state and then begin the new animation.

• Chain the animations so that the newly requested one commences when the current one finishes.

Either solution would repair the reported problems: fixing the perceived brokenness and indeterminate behavior issue. If smoothness of animation is preferred, then chaining animations would be more appropriate than jumping the current animation to its end state.