Using CSS Transitions on Auto Dimensions

We've all been there. You've got an element you want to be able to collapse and expand smoothly using CSS transitions, but its expanded size needs to be content-dependent. You've set transition: height 0.2s ease-out. You've created a collapsed CSS class that applies height: 0. You try it out, and... the height doesn't transition. It snaps between the two sizes as if transition had never been set. After some fiddling, you figure out that this problem only happens when the height starts out or ends up as auto. Percentages, pixel values, any absolute units work as expected. But all of those require hard coding a specific height beforehand, rather than allowing it to naturally result from the size of the element content.


If you were hoping I had a magical, complete solution to this problem, I'm sorry to disappoint you. There's no one solution that achieves the desired effect without downsides. There are, however, multiple workarounds that each come with a different set of advantages and disadvantages, and in most use cases at least one of them will get the job done in an acceptable manner. I'll outline the major ones, and list out their ups and downs so you can hopefully pick the best one for your situation.


Permalink to this heading.Technique 1: max-height

If you web search this problem, the max-height approach will probably be mentioned in all of the first five to ten results. It's actually pretty unideal, but I thought it was worth including here for the sake of comparison.

It works like this: CSS values can only be transitioned to and from fixed unit values. But imagine we have an element whose height is set to auto, but whose max-height is set to a fixed value; say, 1000px. We can't transition height, but we can transition max-height, since it has an explicit value. At any given moment, the actual height of the element will be the maximum of the height and the max-height. So as long as max-height's value is greater than what auto comes out to, we can just transition max-height and achieve a version of the desired effect.


Permalink to this heading.Technique 2: transform: scaleY()


Implementation works like this: we set a transition for the element's transform property, then toggle between transform: scaleY(1) and transform: scaleY(0). These mean, respectively, "render this element at the same scale (on the y axis) that it starts out at" and "render this element at a scale of 0 (on the y axis)". Transitioning between these two states will neatly "squish" the element to and from its natural, content-based size.

Permalink to this heading.Technique 3: JavaScript

Managing a CSS transition in CSS would be ideal, but as we're learning, sometimes it just isn't entirely possible.

If you absolutely have to have smoothly collapsing sections, whose expanded size is completely driven by their content, and which other elements on the page will flow around as they transition, you can achieve that with some JavaScript.

The basic strategy is to manually do what the browser refuses to: calculate the full size of the element's contents, then CSS transition the element to that explicit pixel size.


Using the Page visibility API to optimize an application for background

Web developers should be aware that users often have a lot of tabs open in the background and it can have a serious effect on power usage and battery life. Work in the background should be kept to a minimum unless it’s absolutely necessary to provide a particular user experience. The Page visibility API should be used to detect when page is the backgrounded and suspend all unnecessary work like visual updates.


var doVisualUpdates = true;
document.addEventListener('visibilitychange', function(){
  doVisualUpdates = !document.hidden;
function update() {
  if (!doVisualUpdates) {


hyperHTML: A Virtual DOM Alternative

The easiest way to describe hyperHTML is through an example.


// this is React's first tick example
function tick() {
  const element = (
      <h1>Hello, world!</h1>
      <h2>It is {new Date().toLocaleTimeString()}.</h2>
setInterval(tick, 1000);
// this is hyperHTML
function tick(render) {
      <h1>Hello, world!</h1>
      <h2>It is ${new Date().toLocaleTimeString()}.</h2>
setInterval(tick, 1000,

Permalink to this heading.Features

  • Zero dependencies and it fits in less than 2KB (minzipped)
  • Uses directly native DOM instead of inventing new syntax/APIs, DOM diffing, or virtual DOM
  • Designed for template literals, a templating feature built in to JS
  • Compatible with vanilla DOM elements and vanilla JS data structures *
  • Also compatible with Babel transpiled output, hence suitable for every browser you can think of

* actually, this is just a 100% vanilla JS utility, that's why is most likely the fastest and also the smallest. I also feel like I'm writing Assembly these days ... anyway ...


xo - JavaScript happiness style linter

A screenshot of several JavaScript linting errors.

Opinionated but configurable ESLint wrapper with lots of goodies included. Enforces strict and readable code. Never discuss code style on a pull request again! No decision-making. No .eslintrc or .jshintrc to manage. It just works!


Permalink to this heading.Highlights

  • Beautiful output.
  • Zero-config, but configurable when needed.
  • Enforces readable code, because you read more code than you write.
  • No need to specify file paths to lint as it lints all JS files except for commonly ignored paths.
  • Config overrides per files/globs. (ESLint doesn't support this)
  • Includes many useful ESLint plugins, like unicorn, import, ava, and more.
  • Caches results between runs for much better performance.
  • Super simple to add XO to a project with $ xo --init.
  • Fix many issues automagically with $ xo --fix.
  • Open all files with errors at the correct line in your editor with $ xo --open.
  • Specify indent and semicolon preferences easily without messing with the rule config.
  • Great editor plugins.


Understanding the Critical Rendering Path

A visual representation of the critical rendering path. See text following image.

When a browser receives the HTML response for a page from the server, there are a lot of steps to be taken before pixels are drawn on the screen. This sequence the browsers needs to run through for the initial paint of the page is called the "Critical Rendering Path".

Knowledge of the CRP is incredibly useful for understanding how a site's performance can be improved. There are 6 stages to the CRP -

  1. Constructing the DOM Tree
  2. Constructing the CSSOM Tree
  3. Running JavaScript
  4. Creating the Render Tree
  5. Generating the Layout
  6. Painting