Content Choreography — Why Our Float Based Approach To Layout Should Evolve

The easiest way to rearrange a design’s layout for different devices and conditions is simply to drop one column below another when space no longer allows them to sit side by side. It may be easiest, but it’s hardly the best approach.

Today I want to look at a major consideration of responsive design, one that I think is going to drive all our thoughts about layout for several years to come.

It’s something Trent Walton first called attention to a couple of years ago with a post on content choreography. It’s an issue I ran into around the same time when working on the current design of this site. And it’s something I wrote about for Smashing Magazine earlier this year.

Column Drops aren’t Enough

The problem with dropping columns is it’s a nuclear response done for our convenience and not our visitors benefit. If something is important enough to display at the top of the page when the browser is wide enough, why do we drop it far down the page, when the browser is narrower? Has it suddenly taken on less importance than all the content above it? Not likely.

A better approach is to rearrange all the different blocks of content so that the most important is always the most visible and the least important is always the least visible. Better is to maintain the same hierarchy on narrow screens and wide screens and that requires more fine-grained control than dropping one column in its entirety below another.

There are two challenges to overcome if we want this fine-grained control.

In single column layouts the order elements display is the order they’re written in the html source code. How can we get around this issue of source order being the same as display order

It’s difficult, if not impossible, for elements inside one container to intermix with elements inside another container. How can we gain more granular control over the placement of elements?

Source Order

There really isn’t any way around the first problem at the moment, outside of writing complex Javascript to build your layout. It’s a constraint we have to accept a little while longer. A little while isn’t forever, though.

Flexbox breaks the dependence on source order and after experimenting with them a little, css grids will do to the same. The former has pretty good browser support right now and should be ready for production in the not too distant future. The latter is less supported and it will be a bit longer before we’re using it regularly. Both will render the problem of source order meaningless in time.

The solution to the source order problem, as well as several other development problems is patience. A bit longer and things like flexbox, css grids, css regions, and other technologies on the way will solve a lot of issues for us.

Containers Restrict Movement

The issue of intermixing elements inside containers doesn’t have a technical solution on the horizon and it may never have one. The solution is really more about us rethinking our use of containers in html.

rethinking our approach to html containers and using less of them is the fundamental challenge we’re going to face as we create responsive layouts over the next few years

By definition containers, contain. We wrap blocks of content in containers, because containers make developing layouts easier. It’s much easier to float a container that holds several blocks than it is to float each of the blocks individually. The latter can be done, but it usually leads to more and more complex css.

The downside is what’s inside one container, can’t easily jump into another container and reflow with the content there. In fact, we can only make it appear content in one container has moved to another through complicated css. It takes something like Javascript to actually remove something from one container and place it in another.

What we want is to be able to rearrange smaller blocks of content independently of each other. The ideal is to be able to place content anywhere in a design based on the device and conditions being used to access it. And then be able to place it somewhere else for a different device and under a different set of conditions

However, in wrapping containers around multiple blocks, we remove the independence between the blocks. We make things less modular and less flexible when we add more containers.

Containers giveth and they taketh away. They make it easier for us to develop a layout, but they become restrictive when the layout needs to change. A different layout tends to want a new set of containers.

The solution to the container issue is to rethink our use of html containers, mainly with an eye toward using less of them.

Breaking Free from Containers

This idea of rethinking our approach to html containers and using less of them is the fundamental challenge we’re going to face as we create responsive layouts over the next few years.

Switching from absolute to relative measurements is easy. Determining when best to set a breakpoint is a matter of having the experience of few responsive sites behind you. Presenting flexible media, while difficult today, will get it’s technical solution before too long.

Deciding which blocks of content need to reflow and how they can be reflowed is what design is going to be about. The decisions will change from one design to the next based on content priority and more and more of our time during design will be to resolve this question.

This is the real flexibility we need to embrace as responsive web designers; the flexibility to rearrange blocks of content based on the content and not because technology makes it easy to rearrange them in a certain way.

It will be difficult because we’ve come to rely on containing things in columns that we float left and right. Our present calls for containers. Our future calls for breaking free from them. Fewer containers will make development with floats more difficult so we should start thinking of new approaches.

On the bright side, both flexbox and css grids will help as each reduces the reliance on floats. Each still places content in containers, but fewer of those containers are required to achieve the desired layout.

However, with or without flexbox and css grids we’re going to have to rethink how we design and develop layouts. Greater consideration is going to have to go into managing more small blocks instead of a small handful of large ones.

Given the current practice of float driven layouts.

More containers lead to less flexible layouts that are easier to develop

Less containers lead to more flexible layouts that are mare challenging to develop

How we develop responsive layouts is going to be how we think about our html structure. Responsive design calls for more flexibility and modularity, but the way we’ve been structuring html is far less modular than we sometimes realize.

We should be moving toward fewer html containers, which likely means something other than floats to drive layout development.