When transitioned CSS properties are changed back to back, especially when the next property change starts before any previous transition has finished, the result is a herky-jerky look and feel of the overall effect (because the next transition stops the previous, and starts out slowly). Removing the transition (or setting it to 0s temporarily) during the period of rapid property changes may or may not be smooth enough either. What I really want is a decent way to tween from one transition to another seamlessly, especially in cases where one transition hasn't quite finished before another begins.

Use Case: when properties are rapidly changed via JavaScript
------------------------------------------------------------

Say an element is being dragged via mouse or touch. Browsers fire those mouse/touch events when it's convenient for them, and browsers don't always fire such events in a timely fashion. Usually they are indeed fired smoothly, but sometimes there can be a significant delay between two events firing. The resulting effect can either be jerky or choppy, depending on whether or not you have a transition set on the element (see Dilemma). Ideally, transitions ***should*** be capable of smoothing out the overall effect, **if only there was a CSS property that tells the browser to continue subsequent transitions with the same rate of speed as any currently animating transitions rather than stop the current one before starting the next**. I haven't come across such a property yet, though.

Specific Example
----------------

Take for instance an element moving across the screen (to keep it simple). Say there's a button that triggers the element to move between a designated start and end position on the screen, the 'animation' for which is handled via `transition: 1s` then adding a class that changes the location of the element via a transform property. Voila, the element is 'animated' from its start to its end position. Now say you want the user to also have the ability to drag or swipe the element from between its start and end positions. Naturally, this would be handled via some JavaScript (for now, perhaps until HTML6—as the HTML5 `draggable` attribute doesn't work for the majority of touchscreens/mobile devices yet anyway).

So, you'd set up your event listeners for the mouse/touch events, and handle the transformation of the movable element via `mousedown`/`mousemove` or `touchstart`/`touchmove`, setting a relevant transform value with each movement. Then when they let up on the mouse or touch (`mouseup` or `touchend`) you'd finish moving the element to its end position (or move it back to its start position, if desired) by removing the dynamic styles applied by the `mousemove` or `touchmove` events, and perhaps adding a class that would move the element to its end position if certain conditions are met.

The dilemma
-----------

If you DON'T dynamically set the transition to 0s while the element is being dragged, then each time a transitioned property is changed, if a previous transition is still going, it stops dead in its tracks and a new transition starts from the stopped point, resulting in a herky-jerky effect. 

If you DO dynamically set the transition to 0s while the element is being dragged, then when there's a significant delay between two event firings, and the result is a significant change in position, the element just jumps to the new position immediately, rather than smoothly transitioning to the new position, resulting in a choppy.

Solution Attempts
-----------------

I've thought of several potential workarounds, but they aren't exactly ideal. 

The first is to watch for significant delays between events (or their reported coordinates) and react accordingly by changing the dynamically-set transition property from 0s to something that will animate the transition, but that would likely get cancelled almost immediately by the next event firing which would either change the dynamic transition property back to 0s or else change the position of the element with the dynamic transition still set from the previous transition, causing that transition to stop and the next to start from current position. It also adds extra overhead to the JavaScript code, which I'm not a fan of if there's a better way.

Another is to use `transition-timing-function: cubic-bezier(0,1,0,1)` for the subsequent transitions, which causes subsequent transitions to start out much faster, but they also end much faster, which isn't necessarily desirable. Also, this approach still has a slightly odd feel to it due to noticeable stuttering when transitioned properties are changed extremely quickly. At least that was my experience in Chrome. It looked smoother when the rate of changes to transitioned properties were not quite so rapid-fire (e.g. slower dragging of the element across the screen).

There is also [this question](https://stackoverflow.com/questions/16470591/smooth-out-rapid-javascript-driven-position-changes-with-css-transitions), for which the only solution posted also fails to make the overall effect smooth. That solution has the same exact stuttering flaw I mentioned above for rapid-fire changes to properties transitioned with a higher duration of 1s.

It would be a whole lot simpler if there were a CSS property for transitions that tell the browser to continue into a subsequent transition at the same pace without stopping the one nor starting the other from a stand-still. I haven't found such a property yet, however.

If no such property exists yet, is there a better approach to smoothing out such rapid-fire changes to transitioned properties? 

Here's some very simple [demo code](http://jsfiddle.net/794sx/), which is unfortunately too simple to exhibit the laggy event firing I speak of, but at least it's a starting point. If I get no decent responses, I'll try to make a more advanced example that utilizes more computational power, to make the event firing lag more evident.