Building Resilient Layouts

rigid UIs cause problems for future you

One of my favorite games to play as a kid was Jenga. The goal was to take turns removing blocks from a tower without toppling it. Whoever made the tower fall over lost and deservedly became the object of scorn of the other player(s). Fun stuff.

When you first start, the tower is rock solid and it's pretty hard to make it fall over from removing just one piece. As the game continues, the tower gets further and further from the original state to the point where any tiny movement can totally compromise its structural integrity.

Jenga tower layouts

If you've worked in the web space for any amount of time, you've probably encountered or even created Jenga tower layouts in your UIs. Once a layout is "finished", it works great but the moment something needs to be changed or repurposed, the whole thing falls apart. Overflowing and cut-off text, mismatched and inconsistent spacing, stacking context issues, and smushed or stretched elements are common issues often seen in poorly composed layouts.

Creating a reilient layout right from the beginning can be challenging but will significantly reduce the maintenance burden later on. Here's four tips to give your layouts the flexibility they need to perform well in various conditions.

1. Stop using flexbox for everything

There's two main reasons many developers default to flexbox for almost everything:

  1. It has a pretty simple API and mental model that primarily deals with one axis
  2. It creates very flexible layouts that are self-determining

Here's the two main problems:

  1. Many layouts deal with two axes for which flexbox is usually ill-equipped
  2. Flexibility begets unpredictability so you'll often get surprising, unintended behavior

You need to learn how to use grid positioning if you are a professional front end engineer. There are certainly cases where you'll want to reach for flexbox, particularly if you need an element's content to determine how large it will be, but most layout problems are best served by leveraging grid.

When you create a grid-like layout with a flexbox salary you end up with layout issues that are "fixed" with silly stuff like:

As a side note, you absolutely should use tables for layouts or components that are tabular. In the early days of the web, almost all layouts (and emails) were created with tables which caused a lot of headaches because they cause some really annoying problems when they're used for other things other than tables. There was a bit of an overreaction in parts of the webdev commmunity where the thought was using any tables for anything ever was very bad. But this is wrong and table elements and positioning should in fact be used for tables (and nothing else).

2. Use container queries

It seems like almost every web application in 2025 uses a sidebar on desktop screens that collapses into a slideout menu on mobile. This is a great UX pattern but this causes some annoying layout problems that viewport media queries aren't great for fixing.

If your sidebar shows only on screens larger than 1024px, your main content will actually be wider at 1023px than it is at 1025px. The caveman way of reflowing your content using media queries usually looks like this:

Gross. But the good news is container queries have been supported in all major browsers for over a year and a half from the time of writing and they simplify this problem immensely. Just put a container query on the top level of your main content container and use one single query of that container's width to determine how your content should reflow.

3. Find creative uses for CSS variables

A popular programming principle is to avoid using "magic numbers". This means using semantically named constants instead of dumping arbitrary numeric values with unclear purpose into functions. This practice has carried over into CSS with design systems using CSS variables as tokens to enforce design constraints. It's far easier to create consistent and on-brand UIs when you use a design system with CSS variables.

But you can also use CSS variables for more than just design systems. They are also a great way to group related values for a particular element. Adam Wathan recently released a fantastic short video series where he repeatedly uses this smart technique. A single variable is attached to the top level element of a component becomes the single source of truth for a value that is repeated multiple times in its children. Instead of updating a value three or four times, the one variable can just be updated, saving time and reducing layout bugs.

4. Put constraints on content you don't manage

For marketing websites, content is typically managed by a third party through a content management system. You should assume at some point the person resposible for managing the content will try to dump 200 lines of text into the hero section and totally break everything.

Ideally, you should test what happens to different website sections when there's a cartoonishly large amount of content put into them but the best place to stop the layout from breaking is at it's source. Unless it's a blog post or some other sort of longform writing you need to enforce a sensible character limit in the content management system for different text content sections. Even if it doesn't break the layout, per se, you should preemptively prevent scenarios where the website would look stupid or convert poorly because of a wall of text where it shouldn't be.

Also, it's important to test really long strings within text and see how they perform in different layouts and components. Your content managers might not be using "supercalifragilisticexpialidocious" very often in their writing but pasting a website url with a very long query string at the end might break your layout in some scenarios since there's no sensible place for the browser to break the word. Wrapping the extra long word in a span with a word-break: break-all; or word-break: break-word; style can often alleviate this concern.

There may be scenarios where you can't enforce content constraints from within a CMS and you'll need to get creative to ensure content displays correctly. Clipping or truncating text can be appropriate if excessive superfluous text comprimises the integrity of the layout.

Putting it together

Creating resilient layouts is ultimately about anticipating change and designing for adaptability. By moving beyond the flexbox-for-everything approach, leveraging container queries, using CSS variables strategically, and establishing sensible content constraints, you can build UIs that withstand the inevitable shifts in requirements and content. Just like a well-structured Jenga tower can withstand the removal of several pieces, a thoughtfully constructed layout can accommodate modifications without collapsing. Remember that the most elegant code isn't just about what works today, but what continues to work smoothly tomorrow. Your future self (and anyone else who touches your code) will thank you for taking the time to build resilient layouts.