Interesting way to go about it. Thanks.

The YUI 3 Transition module provides both a start & end method for you as well as falling back to timer-based animations for numeric properties. It's really awesome.

How does this correlate to jquerys fadeOut() for example?

I like your transitionStart idea, as it leaves the door open for a transitionEnd callback. CSS transitions could really use this.

Here's some similar thinking on the subject by Florent Verschelde:

http://fvsch.com/code/transition-fade/

If I'm understanding you correctly, this is similar to how the Twitter bootstrap pulls off the same effect, but they do it a little differently. They use the following (LESS):

.fade {
.transition(opacity .15s linear);
opacity: 0;
&.in {
opacity: 1;
}
}

But I still hate that we have to get JS in the mix.

I think the issue with tracking transitions with transitionStart or :transitioning is that you don't know which transition is working. You could have an element with two classes, one with a 1s transition of color and one with a 3s transition of scale, for example.

Spec-wise, I'd love it if transitions actually handled non-animating properties instead of ignoring them. If you include something like display in the list of properties to transition, it should know that even though it can't go smoothly from one state to the other, it should jump at the end instead of the start. Even if it just respected the delay options, this would be all you need.

This was a good read, thank you. I myself has solved some similar issues by using applying the opacity transition first and a minimal setTimeout() to delay .is-hidden.

If I've understood the problem correctly... I think you can achieve the fade out affect and hiding the element, with a width and height of zero, overflow hidden, and positioned negatively, off-screen. avoiding the need for display none.

Sorry Jonathan, my explanation could have been more clear. I was thinking about multiple properties being transitioned on the same element but with different durations. An example from http://www.webkit.org/blog/138/css-animation/ :

div {
-webkit-transition-property: opacity, left;
-webkit-transition-duration: 2s, 4s;
}

In this case "opacity" would stop transitioning in 2 seconds, but "left" would stop in 4 seconds. At what time would the :transitioning pseudo-class be removed? What if each of these transitions were under different selectors, but applied to the same element, such as

<div class="transOpacity transPosition">

.transOpacity {
-webkit-transition-property: opacity;
-webkit-transition-duration: 2s;
}
.transPosition {
-webkit-transition-property: left;
-webkit-transition-duration: 4s;
}

Different start, end, and duration of property transitions can really at a lot of richness to animation when done well. I'd be against a spec change if it limited our ability in that regard.

Just my thoughts on the pseudo-class suggestion.

Brilliant Jonathan! I was using a chained animation that started with the element positioned off-screen and opacity 0. Animate in a chain - first bring it on-screen in a 0s transition and then do the rest of the animation as a later stage in the animation chain. This is much simpler! :)

If we're going to start changing the spec, let's change correctly. The simple solution is to allow non-transitionable properties not to change unit the transition is supposed to start. e.g. this CSS should be enough:

.dialog {
  transition-property: opacity, display;
  transition-duration: 0.5s, 0;
  transition-delay: 0, 0.5s;
}

Other than that, this seems like a fairly elegant solution.

jonathan, with this approach how do you handling animations for legacy browsers? Do you use object detection and provide a javascript fallback or drop the animations all together for these browsers?

I was just thinking, css needs a pseudo-class for :animating.

Thanks, this is very useful. I was thinking a pseudo-class for :animation-complete or :transition-complete, but having :animating or :transitioning could achieve the same results I think.