I'm writing a CSS book

JavaScript archives Compatibility CSS coaching Thidrekssaga QuirksBlog Donations Politics Mobile About COH

sitemapcontact

Transition tests

Today I published my tests of CSS transitions in the desktop and mobile browsers. I created the test cases ages ago, but interpreting the results turned out to be tricky.

Big overview: transitions are supported very well, except in the proxy browsers (which can’t handle this kind of client-side interactivity) and IE9. However, there are a few more subtle problems:

• All WebKit-based browsers except for Safari still require a -webkit- prefix (die! die!) and don’t support the transitionend event.
• When zooming in on a page, desktop Safari and the desktop Blink-based browsers transition elements. This should NOT happen, since the element’s state does not change. This is a serious bug that has been in existence for at least two years — I remember talking to someone about it. Try it here. (Since mobile pinch-zooming is totally different from desktop page-zooming this bug only affects the desktop browsers.)
• Firefox on Android, but not on desktop or Firefox OS, handles quite a few properties in a very ugly, jaggy way. Details here.

Implied values

A CSS declaration is only transitionable if it goes from a numeric value to a numeric value. Thus, display will never transition since it doesn’t have numeric values. An element with height: auto won’t transition, either, since auto is not a number.

The really tricky thing here is default or implied values (desktop, mobile). An element has no letter-spacing defined, and transitions to a state that has letter-spacing: 2px. Should the browser transition it or not? Since the default value of letter-spacing is 0, it should. (Firefox doesn’t, but that’s a bug.)

There are more complicated declarations that can trip you up, though. The most important one is left. What if an element has position: absolute but no coordinates defined? left (and, I suppose, the others) is not 0, as you might expect, but auto, which is not a number and thus can’t handle transitions. All WebKit-based browsers handle this wrong, as do older Chromes. (It was fixed between 30 and 33.)

The most complex declaration is border. Suppose an element has no border defined and then transitions to border: 5px solid red. An element without a border has a border-width: 0, that’s easy. The tricky thing is that border-style uses keywords and thus does not transition.

When transitioning from none to 5px solid red, the border-style is immediately set to solid, while border-width transitions in an acceptable way. The users won’t notice anything. Going the other way, though, border-style is immediately set to none and no transition takes place, which confused me mightily. I actually needed help to figure this out (thanks, Tab).

Anyway, this goes to show that doing the tests is not the problem; interpreting them is. I hope I got them all right.