My article on Friday about overengineering CSS apparently hit a chord with a lot of readers.
CSS before JS
My general rule of thumb is…
CSS parses and renders faster.
For things like animations, it more easily hooks into the browser’s refresh rate cycle to provide silky smooth animations (this can be done in JS, too, but CSS just makes it so damn easy).
And it fails gracefully.
You can take this rule too far, though
A few years ago, there was an obsession with finding creative CSS hacks for things that would normally be done in JS.
A CSS-only expand/collapse navigation menu is the one that jumps to mind. Here’s an example. These are really cool examples of pushing CSS farther and thinking about code creatively, but…
The results are often wildly inaccessible.
Here’s the demo from the example I linked to. Hover over About or Portfolio. Works great!
Now, reload the page and try to tab through the menu. Nothing shows up. You can access the submenus below those items if you’re a keyboard only user.
A mental model for making decisions
I don’t really have a formal model for choosing when to use CSS vs. JS, but approach to which one to use and when looks like this:
- If the item needs to change in visibility, needs to be animated, or have any other visual change made to is, use CSS.
Often times, these two are combined.
For example, let’s talk about the drop-down menu example we looked at earlier. You can detect focus on the drop-down link with CSS, but once you tab into the links below it, the original link loses focus.
If either of those conditions is true, I would add a class to the dropdown menu that makes it visible. You could also use that class to add animations and do all sort of other fun stuff.
Tomorrow, I’m going to talk about my preferred CSS methodologies, and how I use them to write stylesheets that are absurdly tiny and performant.