Tags: flexbox



Fit For Purpose: Making Sense of the New CSS by Eric Meyer

Time for even more CSS goodness at An Event Apart Seattle (Special Edition). Eric’s talk is called Fit For Purpose: Making Sense of the New CSS. Here are my notes…

Eric isn’t going to dive quite as deeply as Rachel, but he is going to share some patterns he has used.

Feature queries

First up: feature queries! Or @supports, if you prefer. You can ask a browser “do you support this feature?” If you haven’t used feature queries, you might be wondering why you have to say the property and the value. Well, think about it. If you asked a browser “do you support display?”, it’s not very useful. So you have to say “do you support display: grid?”

Here’s a nice pattern from Lea Verou for detecting support for custom properties:

@supports (--css: variables)

Here’s a gotcha:

@supports (clip-path: polygon())

That won’t work because polygon() is invalid. This will work:

@supports (clip-path: polygon(0 0))

So to use feature queries, you need to understand valid values for properties.

You can chain feature queries together, or just pick the least-supported thing you’re testing for and test just for that.

Here’s a pattern Eric used when he only wanted to make text sideways, but only if grid is supported:

@supports (display: grid) {
    @supports (writing-mode: sideways-lr) {

That’s functionally equivalent to:

@supports (display: grid) {
@supports (display:grid) and (writing-mode: sideways-lr) {

Choose whichever pattern makes sense to you. More to the point, choose the pattern that makes sense to your future self when you revisit your code.

Feature queries need to work together with media queries. Sometimes there are effects that you only want to apply on larger viewports. Do you put your feature queries inside your media queries? Or do you put your media queries inside your feature queries?

  • MOSS: Media Outside Support Statements
  • MISO: Media Inside Supports Object

Use MOSS when you have more media switches than support blocks. Use MISO when you only have a few breakpoints but lots of feature queries.

That’s one idea that Eric has. It’ll be interesting to see how this develops.

And remember, CSS is still CSS. Sometimes you don’t need a feature query at all. You could just use hanging-punctuation without testing for it. Browsers that don’t understand it will just ignore it. CSS has implicit feature queries built in. You don’t have to put your grid layout in a feature query, but you might want to put grid-specific margins and widths inside a feature query for display: grid.

Feature queries really help us get from now to the future.


Let’s move on to flexbox. Flexbox is great for things in a line.

On the An Event Apart site, the profile pictures have social media icons lined up at the bottom. Sometimes there are just a few. Sometimes there are a lot more. This is using flexbox. Why? Because it’s cool. Also, because it’s flexbox, you can create rules about how the icons should behave if one of the icons is taller than the others. (It’s gotten to the point that Eric has forgotten that vertically-centring things in CSS is supposed to be hard. The jokes aren’t funny any more.) Also, what if there’s no photo? Using flexbox, you can say “if there’s no photo, change the direction of the icons to be vertical.” Once again, it’s all about writing less CSS.

Also, note that the profile picture is being floated. That’s the right tool for the job. It feels almost transgressive to use float for exactly the purpose for which it was intended.

On the An Event Apart site, the header is currently using absolute positioning to pull the navigation from the bottom of the page source to the top of the viewport. But now you get overlap at some screen sizes. Flexbox would make it much more robust. (Eric uses the flexbox inspector in Firefox Nightly to demonstrate.)

With flexbox, what works horizontally works vertically. Flexbox allows you to align things, as long as you’re aligning in one direction. Flexbox makes things springy. Everything’s related and pushing against each other in a way that makes sense for this medium. It’s intuitive, even though it takes a bit of getting used to …because we’ve picked up some bad habits. To quote Yoda, “You must unlearn what you have learned.” A lot of the barrier is getting over what we’ve internalised. Eric envies the people starting out now. They get to start fresh. It’s like when people who never had to table layouts see code from that time period: it (quite rightly) doesn’t make any sense. That’s what it’s going to be like when people starting out today see the float-based layouts from Bootstrap and the like.


That’s going to happen with grid too. We must unlearn what we have learned from twenty years of floats and positioning. What makes it worth is:

  1. Flexbox and grid are pretty easy to get used to, and
  2. It’s amazing what you can do!

Eric quotes from an article called How We adopted CSS Grid at Scale:

…we agreed to use CSS Grid at the layout level and Flexbox at the component level (arranging child items of components). Although there’s some overlap and in some cases both could be used interchangeably, abiding by this rule helped us avoid any confusion in gray areas.

Don’t be afraid to set these kind of arbitrary limits that aren’t technological, but are necessary for the team to work well together.

Eric hacked his Wordpress admin interface to use grid instead of floats for an activity component (a list of dates and titles). He initially turned each list item into a separate grid. The overall list didn’t look right. What Eric really needed was a subgrid capability, so that the mini grids (the list items) would relate to one another within the larger grid (the list). But subgrid doesn’t exist yet.

In this case, there’s a way to fake it using display: contents. Eric made the list a grid and used display: contents on the list items. It’s as though you’re saying that the contents of the li are really the contents of the ul. That works in this particular case.

The feature queries for that looked like:

@supports (display: grid) {
    @supports (display: contents) {

Eric is also using the grid “ASCII art” (named areas) technique on his personal site. This works independent of source order. For that reason, make sure your source order makes sense.

Using media queries, Eric defines entirely different layouts simply by using different ASCII art. He’s switching templates.

For a proposed redesign of the An Event Apart site, Eric used CSS grid as a prototyping tool. He took a PDF, sliced it up, exported JPGs, and then used grid to lay out those images in a flexible grid. Rapid prototyping! The Firefox grid inspector really helps here. In less than an hour, he had a working layout. He could test whether the layout was sensible and robust. Then he swapped out the sliced images for real content. That took maybe another hour (mostly because it was faster to re-type the text than try to copy and paste from a PDF). CSS makes it that damn easy now!

So even if you’re not going to put things like grid into production, they can still be enormously useful as design tools (and you’re getting to grips with this new stuff).

See also:

100 words 033

Charlotte came up with a nifty trick that combines two different techniques she’s been working with.

The first building block is the pattern of using checkboxes, labels, and the :checked pseudo-class to create progressive disclosure toggles without JavaScript. There’s just one caveat with that technique though—the item being toggled must appear after the trigger label in the source order of the markup.

Enter the second building block: flexbox. With flexbox, we’re no longer at the mercy of the source order in our markup. By using flex-direction: column-reverse, the progressive disclosure trigger can be displayed after the item being toggled.


I was in Minnesota last week for An Event Apart Minneapolis. A great time was had by all. Not only were the locals living up to their reputation with Amy and Kasia demonstrating that Kristina isn’t an outlier in the super-nice, super-smart Minnesotan data sample, but the conference itself was top-notch too. It even featured some impromptu on-stage acrobatics by Stan.

A recurring theme of the conference—right from Zeldman’s opening talk—was Content First. In Luke’s talk it was more than a rallying cry; it was a design pattern he recommends for mobile: content first, navigation second. It makes a lot of sense when your screen real estate is at a premium. You can see this pattern in action on the Bagcheck mobile site (a button at the top of screen is simply a link that leads to the fragment identifier for the navigation at the bottom).

Later on, Eric was diving deep into the guts of the CSS3 flexible box layout module and I saw an opportunity to join some dots.

Let’s say I’ve got a document like this with the content first and the navigation second:

<div role="main">
<p>This is the main content</p>
<nav role="navigation">
<p>This is the navigation</p>

Using box-orient:vertical and box-direction:reverse on the body element, I can invert the display of those two children from the order they appear in the source:

body {
    display: box;
    box-orient: vertical;
    box-direction: reverse;

If I wrap that in a media query, I can get the best of both worlds: content first, navigation second on small screens; navigation first, content second on larger viewports:

@media screen and (min-width: 30em) {
    body {
        display: box;
        box-orient: vertical;
        box-direction: reverse;

Works a treat (once you include the necessary -webkit and -moz prefixes).

I thought I’d take it a bit further. Suppose the navigation has a list of links:

<nav role="navigation">
<p>This is the navigation.</p>
<li><a href="#">foo</a></li>
<li><a href="#">bar</a></li>
<li><a href="#">baz</a></li>

I could use flexbox to lay those items out horizontally instead of vertically once the viewport is large enough:

@media screen and (min-width: 30em) {
    [role="navigation"] ol {
        display: box;
        box-orient: horizontal;
    [role="navigation"] li {
        box-flex: 1;

Here’s the weird thing: in Webkit—Safari and Chrome—the list items reverse their direction: “baz, bar, foo” instead of “foo, bar, baz.” It seems that the box-direction value of reverse is being inherited from the body element, which I’m pretty sure isn’t the right behaviour. But it can be easily counteracted by explicitly declaring box-direction: normal on the navigation.

What’s a little trickier to figure out is why Firefox is refusing to space the list items equally. I’ve put a gist on Github if you want to take a look for yourself and see if you can figure out what’s going on.

Update: You can see it in action on JSbin (resize the view panel).

The new CSS3 layout modules and responsive design could potentially be a match made in heaven …something that Stephen has been going on about for a while now. Check out his talk at Mobilism earlier this year.

You’ll notice that he’s using a different syntax in his presentation; that’s because the spec has changed. In my example, I’m using the syntax that’s currently supported in Webkit, Gecko and Internet Explorer. And, as Eric pointed out in his talk, even when the newer syntax is supported, the older vendor-prefixed syntax won’t be going anywhere.