Transition Grid

The Goal

A client had a large grid of identically sized elements that responded to simple filtering, sorting and resizing. Floating the elements kept them in a reasonable position, but it was a bit lacking - there's no way to animate floats when they change position, making a change very abrupt to the end user. We considered using Masonry to add a dynamic touch to it, but somehow that felt like overkill - a full JavaScript positioning library seemed like too much for what essentially amounted to animating transitions for floats.

To state the problem plainly: if you have a grid of identically sized elements, is there a way to animate changes to their layout with pure CSS?

Basic Approach

As mentioned above, floats won't cut it. Floats can figure out where to be, but the move is automatic and immediate - there's no way to apply a transition to the change. The positions of the elements must be fully expressible as properties that can have transitions applied to them like margin, top, height, etc.

Doing so commits us to quite a bit of CSS. At a minimum, each cell in a row will need to have it's own left/top properties. Without these, there's nothing to animate when the layout changes. This would be prohibitively tedious and inflexible with purely traditional CSS, but SASS makes this manageable.

The core idea is to have a mixin that generates a series of media queries for however many columns you might have. A query will need to have detailed rules for a single rule - in particular, each cell in a row must have a distinct left value - but the rows should be able to follow another row without any personalized CSS. This does some sacrifice some of the flexibility that floats offer. The maximum number of columns must be specified before hand, and the size of each cell must be constant. This also can generate an absurd amount CSS, but even a rather extravagant 20-column grid minified and gzipped takes less than 2 KB, compared to 25 KB for Masonry.

Another key property is that however many cells are in a row, their total heights must be exactly the same as one cell. This is to ensure that the following row can be positioned in an extensible manner: a relative block is placed relative to where the prior block should have been positioned.

My first thought was to zero out the height of each cell following the first - if only the first cell in a row had height, then the following row would line up perfectly. The content itself, of course, couldn't have zero height - but a container with visible overflow could.

And with that, we have a fully functional, CSS-driven responsive grid:

Refinement

This worked, but I was unhappy with the requirement of having a wrapper element. Ideally, a cell could be directly positioned without any additional DOM elements. Fortunately, a cell needn't have a physically zero height for positioning purposes. For calculating position, both height and margin are used. Negative margins are a perfectly legal part of the CSS spec, so rather than have a wrapper that has zero height, the cells could be given a negative margin equal to the height.

There are a few simple ways to add some flexibility to the grid. A base offset can be added, such that the grid does not begin adapting the structure until a certain point. So, if we set an offset of 200px on a centered grid, it acts as if there's 100px of padding on the left and the right. Another tweak is to let the space the grid occupies grow at a different rate than the window, so the grid could be set to try to fill only 70% of the window width rather than 100%. These options can be used for more sophisticated layouts (like adding a column next to the grid), or just to give the grid some space to breathe.

You can find a pen of the final version here.

Altogether...

There are a few cases where this would be useful, but I feel it ultimately falls short. The optional adjustments give a little bit of flexibility, but not enough. It does work quite well when the grid unambiguously dominates the page horizontally, but if the page wants to section off & manipulate the grid container, things may not quite work. What it comes down to is that it can't be added to a section and forgotten about: if this is part of your page, you may be thinking about more than you'd like.

One thing that might make an approach like this practical is if element queries ever take off. As-is, the grid must be aware of the environment around it. If the responsiveness of the grid could just depend on the sizing of the parent opposed to the entire page, it would make this a practical, drop-in solution. However, since this proposal is nowhere near the official w3c spec, I won't be holding my breath.