Why I Built This

Every few months I sit down to use Flexbox on something slightly unusual — maybe a layout that needs align-content instead of align-items, or a wrapping row where flex-shrink starts doing unexpected things — and I realise I've forgotten the exact behavior again.

Reading the MDN docs helps, but what actually makes it stick for me is manipulating it live. So I built the Flexbox Builder in Mahrokh Labs — a playground where you can poke at every Flexbox property, watch the layout respond instantly, and copy the generated CSS when it looks right.

It started as a personal scratch pad. Then it got useful enough that I wanted to share it properly.

What the Flexbox Builder Actually Does

The experiment lives under the CSS Playground category in Labs. Here's what you get:

Container controls — flex-direction, flex-wrap, justify-content, align-items, align-content, and gap. All adjustable via dropdowns and sliders, no typing required.
Item controls — you can select any individual flex item and tweak its flex-grow, flex-shrink, flex-basis, align-self, and order.
Live preview — the canvas updates on every change. No refresh, no delay.
Code output — the current state is always reflected as ready-to-copy CSS. What you see is exactly what gets generated.

The goal was to make it feel like DevTools, but without needing DevTools open.

A Few Things Building This Made Me Re-Learn

I knew Flexbox well going in, or so I thought. Writing a playground that has to handle every valid combination of properties has a way of surfacing gaps.

The one that caught me off guard: align-content does nothing unless flex-wrap is set to wrap or wrap-reverse. Sounds obvious in writing. But I'd written UI controls for it and couldn't figure out why nothing was happening on single-line containers. I stared at it for longer than I'd like to admit.

Another one: flex-basis and width interact in ways that are subtle depending on the flex-direction. When you're going column, flex-basis controls the height, not the width. That tripped up my code generation logic twice.

Building tools that teach a concept forces you to understand that concept at a deeper level than just using it does.

How I Structured the State

The builder has two kinds of state: container-level (applies to the flex parent) and item-level (applies to individual children). Managing both without them getting tangled was the main architectural challenge.

I kept them separate — container state in one object, items as an array of objects each with their own properties. Selecting an item just sets an active index; the controls panel reads from and writes to items[activeIndex]. Simple, and it made the code generation straightforward: iterate items, produce per-item rules, then output the container rule.

The CSS output is generated on every state change with a pure function — no side effects, no refs, just stateToCSS(state) that returns a string. That made it easy to test and easy to reason about.

What's Next for This Experiment

A few things I want to add when I get time:

The ability to add and remove flex items from the playground, not just configure the existing ones
A preset gallery — common layout patterns like sticky footer, centered card, sidebar layout — that you can load and then customize
A share link that encodes the current state in the URL so you can send a specific layout to someone

If you have other ideas, I'd genuinely love to hear them. Labs is a place where I'm building things I actually want to use, so if something is missing that would make this more useful for you too, that matters.

Try It Yourself

The Flexbox Builder is live at /labs/css/flexbox-builder. No account, no setup — just open it and start poking around.

If you've ever stared at a Flexbox layout wondering why justify-content: space-between isn't doing what you expect, this might save you ten minutes of trial and error. Or at least make the trial and error more satisfying.