Welcome to episode fourteen of Front End Center!

How we design and develop the front-end of websites has changed a lot over time. In the beginning, Tim said “Let there be text”, and it was good. Text alone wouldn’t last long, though. Even before the internet became a full global phenomenon, human imagination demanded more.

Colors, links, images, and interactivity quickly poured forth to fill web pages of all sizes. All the functionality in the world won’t do you any good if it isn’t organized and usable though.

For a time, tables filled the need for organization and structure. From an engineering standpoint, it was a logical conclusion. Content could easily and effectively be laid out in an organized format. It was possible to plan content based on its page location, and even in relation to other content! Headers, borders, content, links, everything in its table-cell and everything in a row.

As web development became increasingly accessible, though, developers had to ask themselves if this was the best possible solution. While tables made perfect sense (then AND now) for literally tabular data, did they function well as a skeleton from which to hang everything on the web?

The answer was a resounding NO. But what to replace them with? A flurry of new semantic HTML and accompanying CSS quickly filled the gap. First came the Divs, and they settled the wild frontier. Then came dedicated roles like header, footer, section, and aside. These were held up by CSS design that allowed many kinds of positioning and content-relative floating.

While some more complex layouts weren’t always the most… logical to achieve, these methods are still the go-to method for most developers today. They bridge the gap between modern functionality and feasible backwards compatibility.

The way forward, though, looks a lot more… flex-y?

Flexbox is a new method of object display that reconsiders what sort of arcane magic needs to go into complicated layout methods. Most, if not all, of what a flexbox can do can be backwards-emulated through fairly verbose and specific CSS. As it gains wider and wider browser support though, leveraging flexboxes will allow front-end development to become leaner, less brittle, and more reliable in many, many ways!

So what can the little miracle boxes do, you ask? Let’s dig in.

First and foremost, flexboxes make centering EASY. Centering various forms of multimedia content on the web has always been a fun challenge. As we’ve added dynamic content and responsive screen sizing, that fun challenge has regularly orbited through a spectrum of time consuming through downright rage inducing.

Even the most steadfast of modern-table deniers will quickly recommend them if you need to leverage the black-magic of trying to center something vertically as well as horizontally. For such a central component of web layouts, it’s a feature that has been woefully under equipped.

That’s changing with flexboxes. Not only can you leverage horizontal centering for items in a flexbox with a single CSS attribute, but you can do the same vertically! And these two separate attributes are suitably powerful above and beyond their base functionality.

Need to center one thing, horizontally? Justify-content has your back. What if you have two things? Or five? Maybe ten, all with varying and dynamic widths? Fear not. Do you want them stacked on the left or right hand side of the flexbox? Maybe in the center? We can also space them evenly from one edge to the other… or make sure there’s an equal margin on all sides of every element! Justify-content has seen (and aligned) all of it!

Align items will do you the same favors on the other axis, vertically by default. Top or bottom, centered or stretched to a uniform height! You can even set a baseline for the text content within each element, regardless of the height above or below of the overall child container.

Flexboxes also have a fairly unique quality in how they handle both the parent element and its children. Traditionally, styles of two elements would certainly react between each other, but not because of an intrinsic built-in purpose. Flexboxes open a very useful new chapter in relative CSS.

If you want to take advantage of one of the alignments we already discussed, except for a single child element… you can do that! There’s a flexbox child-specific attribute of align-self that lets you customize one (or more) child behaviors, regardless of the general rule being applied at the parent.

In the same way, flex-grow and flex-shrink can dictate how the child elements size themselves within their parent flexbox. One child can resize at a rate multiple times that of its sibling, to maintain a comparable content space at any size of responsive design.

All of this is good, welcome, and honestly much needed for ever quicker adoption. There’s another flexbox attribute that can be contentiously considered one of the biggest game changers. It’s a powerful tool that has generally been the realm of JavaScript until now, and is sometimes questioned as a best-practice from an accessibility standpoint.

Flexbox children have the unique stylistic ability to literally switch their display order. By default, they follow the expected behavior of any other child elements: their display reflects the order of layout from the code.

By manually setting the CSS attribute order, however, we can do some tricky movement that wouldn’t be possible in an otherwise JavaScript free environment.

A flexbox that looks like a tabular layout at larger screensizes can suddenly rearrange itself completely for mobile viewing at a moment’s notice. Unlike a literal HTML table, the content isn’t tied into rigid bodies, rows, and ordered cells. Rather, the child elements are all floating relative to each other, and can be refashioned to suit usability needs with the same semantic elements.

Through careful use of media queries and other CSS conditionals, one set of content could take many different forms and orders to best serve each user’s specific needs and goals.

Like any great power, there is some responsibility to be upheld here. Throwing content into any random order, much less switching positions of functional elements like buttons, can be a recipe for disaster. Developers must take care to carefully shape the User Interface of each condition they set. Additionally, specs like WAI-ARIA have begun to take account of order-swapping functionality like JavaScript and flexbox. They have specific tags and methods to provide the contextual information for accessibility that might otherwise be missing in such a variable environment.

Flexbox is one of many elements slowly coming into the spotlight as HTML5, CSS3, and other modern specs gain uniform browser support. It may be one of THE most impactful though, for its widespread usefulness and ability to interact with so many other elements.

A shout-out to A List Apart this week and their current competition, 10k Apart. For those who haven’t heard yet, it’s a panel-judged contest to create impactful websites using only 10kb of code on the front-end of the site. Back-end processing and functionality is encouraged in this iteration of the competition, but almost everything you load will be counting against your 10kb. Time to trim up those font files and verbose JavaScript libraries!

That’s all for this week, listeners. Until the next episode, this has been Chris Landtiser, and Front End Center.