Keeping the content perfectly vertically centered within the cells is something else that was troublesome at best in a world without flexbox. The center property provided by flexbox, makes this super easy. A very welcome addition to our design arsenal!

Dynamically maintaining height and perfect vertical centering are the big advantages of using Flexbox for a table layout.

Now, let’s look at the table and test it a bit before we go into detail on how this was made. Spoiler: it’s surprisingly simple! The design teardown can be found below the table.

To test this in Responsive Site Designer, just use the width slider up top. You can also preview it in the browser or use the publish function to test the table on mobile devices. If you’re viewing this in a browser simply reduce the window size (width).

Building the flex table.

When viewed in Responsive Site Designer the structure can easily be visualized using the Show Guides dropdown in the toolbar. Simply toggle the selection to show the outline of the Grid Rows, Columns and Containers. Alternatively you can select the Inspector pane and view the elements (DOM) tree — hovering over the elements on the pane will also show their outline.

A free (time limited) version of RSD can be downloaded here. Alternatively, you can load this document in a code editor or use the web inspectors in browsers such as Firefox and Chrome. I also summarized the HTML structure below.

Adding flex properties

Giving the feature-check container a flex-grow of 1 makes it take up the remaining space, but let’s be precise and also specify the flex-basis. This container gets a value of 30%. This already creates the basic table structure. To make this visible we can add some horizontal and vertical borders — these lines will visualize the table cell structure. 

I chose to add a bottom border to the column (I could have opted for the containers) and a left border to the feature-check container (could have been a right border for the feature-text container) to create the structure depicted above.

If one container becomes higher because of a larger amount of content, the other container follows. This behavior is unique to flexbox and is created by the default  stretch setting for align-items on the flex-parent (the column in this case).

The containers are both flex-children (from the column) and flex-parents (for the paragraphs and font icons). By setting the flex-direction to column the paragraphs are stacked (in case there is more than one). The paragraphs and icons are perfectly vertically aligned in their containers thanks to the center setting for the justify-content property.

Responsifying a flex table.

Following the change (use the width slider in RSD to view the actual design adjustment past the breakpoint) it’s clear that this does not create problems for the feature-checks with an icon. However, when these containers hold text, the design feels a bit crammed. To battle that, the font-size of these paragraphs is decreased to 14px. Since they use a double class name selector, the feature-paragraphs are not affected by this change.

To bring the balance back between all these text elements, the font sizes for the category headers and paragraphs is decreased a little as well. Smaller screens are usually a little closer to the eye, creating less of a need for large fonts. But also at a larger distance, the bigger feature paragraphs remain very easy to read at a font-size of 15px.

Several methods can be used to change a flex-based layout at a breakpoint. In this case I changed the column (first flex-parent) back to display block. This will automatically stack them, no further changes are needed. Other than that, it is just a matter of changing the background colors for the different containers (selectors). The feature-group headers get the darkest background (#87827b), while the font color is changed to white. The background of the feature-description container is set to #ededed. The border of the feature-check container is removed but it keeps its white background.

Advantages of this approach are that Javascript is not used and off-screen scrolling by the viewer is not required. Even with more cells this can be a good options as can be seen from the (small) example below.

These unreal sounding features for an email designer are totally real!

Finally the parent containers must have the same dimensional settings to make the lines connect, so no padding for the table-header for example.

Extra containers, column headers with the different versions of the app, have been added to the table header to provide the context for comparing the features. Clearly the containers in the header column have to use the same values for flex-basis in order to get the same distribution of width.

That’s it, a rock solid yet flexible table structure. Now let’s see what is needed to make this version look good on small screens as well.

To place the feature-check containers below the feature-text container we simply have to make sure there is no space available for them. Setting the flex-basis value for the feature-description container to 100% will do the job. Now, with the three feature-check containers below, the only remaining task is to adjust their flex-basis as well. Giving each one of them 33% of the space seems a fair solution.

For feedback or questions, just send me a note on twitter (I do check it and tweet...now and then) or leave a comment in the CoffeeCup forums.

Have a good one!