Jordan Moore
UX Design & Interaction

A picture of my poorly bearded face

17th June 2013

Building for Content Choreography using Flexbox

On July 14th 2011 Trent Walton published an article introducing the concept of Content Choreography. The article opened my mind and made me question some of the limitations we face in how we build responsive experiences. At the time content reordering and reflow hadn’t been widely explored beyond JavaScript-based solutions and I had been experimenting a lot with flexbox to reorder and arrange items horizontally for Typecast’s UI. When Trent spoke about content stacking, I started to think what was achievable for reordering content along the y-axis in a single column layout.

A tale of two syntaxes

The flexible box model landscape has been through a series of fundamental changes since its introduction in 2009. The original syntax for declaring the property in CSS is still recognised in a lot of today’s popular browsers. The following 3 years brought two significant changes to the syntax mainly around the language used to specify flexbox properties.

The flexbox specification has been finalised since I wrote about using flexbox to tackle content choreography concerns in May 2012 so it’s a good time to revisit the approach. Although the new flexbox syntax has been agreed it has not been widely implemented. Since the spec was settled we have witnessed the release of new mobile operating systems like iOS 6 that boasted numerous updates to Safari - one of which refrained from implementing the new syntax and reverted to the old 2009 syntax. At the time of writing it is unclear whether iOS 7 will feature the updated syntax. Android’s default browser still uses the old syntax although Chrome on Android uses the new syntax like its desktop counterpart. That leaves us in some sort of syntax-purgatory between the final specification and the 2009 syntax.

Luckily the changes between old and new flexbox won’t affect how we use it to reorder blocks of content, just how we write the code. Some repetition is required, much like writing vendor prefixes.

The bottom line is that flexbox is safe to use on the web today for content choreography. According to caniuse.com’s global browser usage statistics 76.52% of users would be able to view a flexbox-based solution to content choreography at the time of writing. 23.48% might seem like a considerable amount of people, but when we break that figure down further it’s not quite so big. 23.48% takes the desktop versions of Internet Explorer into consideration and we don’t intend to use this solution that demographic.

Content choreography using flexbox is most reliable at the first major breakpoint (usually in a single column). It’s also easiest at this level because we are (largely) dealing with moving element blocks around vertically on the y-axis. When we approach content choreography from this angle we can assume most desktop browsers won’t see our reordered page. Looking again at the browser statistics for flexbox support among mobile browsers only 14.4% of users won’t see choreographed content.

I don’t usually make decisions based on browser statistics, especially project-specific decisions, but for gauging a general sense of browser support for something previously thought of as an edge-case CSS property, I think it’s worth pointing out that it is as safe to use in this context as something trivial like the text-shadow property.

A note about screenreaders

Before we dive into code specifics, we need to talk about accessibility. Screen readers will not read an altered source order changed by flexbox. Instead they will read the original document order which makes for a jarring and confusing experience for users requiring a service like VoiceOver.

Some feel that for this reason it is better to make source order changes in JavaScript rather than CSS although others counter that this hinders innovation and screen readers simply must follow our lead in pushing the web forward as a platform.

I am firmly in favour of a CSS-based approach as this is fundamentally a layout change after the effect. Using JavaScript instead of CSS to achieve a layout goal that can otherwise be achieved in CSS feels like a Frankenstein approach. I feel it’s dragging us back to the dark ages instead of helping our platform mature. If we choose to remain stagnant on issues like this then it would be like encouraging the use of JavaScript for rollover states in 2013. The fact is we have flexbox at our disposal and specced for use in CSS, avoiding it is only going to encourage the makers of screen reading software to do the same.

A solution for past, present and future

Now that we have covered the fundamentals, there are a few simple considerations to account for when building with flexbox to achieve content choreography. I have found the following mindset helps:

All things considered the revised flexbox code for a definitive specification looks like something this1:


.container {
display: -moz-box;
display: -webkit-box;
display: -ms-flexbox;
display: -webkit-flex;
display: flex;
-moz-box-orient: vertical;
-webkit-box-orient: vertical;
-ms-flex-direction: column;
-webkit-flex-direction: column;
flex-direction: column;
}

.nav {
  -webkit-box-ordinal-group: 1;  
  -moz-box-ordinal-group: 1;  
  -ms-flex-order: 1;     
  -webkit-order: 1;  
  order: 1;
}

...

I have updated the original demo so it considers the new syntax.

Flexbox is no longer the volatile experimental property it once was, now that we have a final specification in place and widespread support on mobile devices flexbox is a robust solution for content choreography exactly where we want it to be — where space is confined and some layout adjustment is required.


  1. Inspiration heavily borrowed from Chris Coyier’s excellent Using Flexbox article 

Powered by Fusion