Dev Blog

In the past couple of months I’ve worked on a project that has pushed and changed my understanding of a couple of things quite far. I’ve sought help with a couple of things for one project and they’ve turned out for the best.

The first of which posed a question in my development style: flexibility vs accessibility.

The root of the problem came from a very simple slide-down menu. I wanted the menu to go from height: 0px; to height: Npx, then using some sort of CSS movement to get it there and back.

Having recently messed around with CSS animations on another project, this seemed the most obvious option. This way I could animate to the height I wanted, and customise the speed (in the last project the designer and I agreed that a Cubic Bezier would fancy-up an animation, so this was the method I chose). So I wrote the code to slide it down, something like this: [CODE HERE]

Starting with the @keyframes, you declare what you want the movement to be. The beauty of animations is that they accept any property – background-color, height or transform properties like scale or translate. This method comes with it’s downsides, however. Firstly, some animations bring performance concerns. Also – as I’ll touch on more later – it’s quite long.

It was in this vein of hassle-free and neat coding that a fellow developer told me that this would become an even lengthier section later. Like a professional used car-salesman, he walked around my code kicking the tires, inhaling sharply and tutting as he told me that I’d need to add -webkit- and -ms- prefixes to every keyframe and every animation, which means the number of lines used is tripled.

Thankfully there are some simpler ways of going about this. Firstly, this could be done via JQuery animation, requiring no prefixes at all. While this does solve the problem, I am of the opinion that anything pertaining to the look and style of the site should, if possible, be kept in the stylesheet. Here I came across a simpler method. It seems I was attempting to run before I was walking, and I’d skipped transitions completely in favour of animations. With transitions you can make any state change smooth and pretty. For example, if you have a hover state that changes a colour, or – in my case – if the body changed to <body class="MenuIsOpen">, so then would the style change. The style would go from:

.menu {
height: 0;
}

to

body.MenuIsOpen .menu {
height: N;
}

All it takes to get this moving smoothly is one line: transition: [property] [duration] [transition type]. So in our example we might use transition: height 0.5s ease-in. However, it occurred to me that there’s rarely anything on your site that you’d want to go from A to B instantly, so it won’t be an issue writing transition: all 0.5s ease-in.

The beauty of this method: That took three lines. Just three. One for the start, one for the result, one to define the transition. So when prefixes triple this, it isn’t much of a hassle. The issue here is the support. While animation supports such fancy-pants features as the Cubic Bezier and Infinite Iterations, transition is a much more stripped-back version. You can make the thing go from here to here, you can make it accelerate or decelerate over however long you want, but that’s it.

This raises the question referred to earlier about which is better: having an animation that can do more things and look fancier for the less-than-one-second it happens, or a transition that’s much more conservative on code, but can’t do as much. In this instance here it’s pretty clear the transition is best, but in more complex situations – things moving and changing colour for whatever reason – animations could be the only recourse. In this case the only option is to stop being lazy and write the prefixes. It’s basically copying and pasting anyway, right? What’s it matter if it takes more lines and makes your code less fluent. – said no-one ever.