We wrote cautiously about flexbox a couple of years back, promising but not ready for anything client-facing given browser support at the time. That calculus has changed enough this year that we're now using it as our default for new navigation and card layouts, a shift we made gradually, starting with lower-risk internal projects again before trusting it on paying client work, the same cautious rollout pattern that served us well the first time around with anything new.
- display: flex on a nav bar replaced a surprising amount of float and clearfix hackery in one line, a navigation bar that used to need a cleared float container, floated list items, and careful width math to avoid wrapping now just needs a flex container and justify-content set appropriately.
- Vertically centering content, historically one of CSS's small daily annoyances, is now trivial, align-items: center on a flex container handles what used to require a table-cell display hack or absolute positioning with a negative margin calculated from a known height.
- We still keep a float-based fallback in mind for the handful of older browsers still showing up in a couple of clients' analytics, but it's a shrinking minority, we checked actual analytics data across our active client sites before making this the default rather than guessing, and the affected browsers now represent a small enough slice of traffic that a slightly degraded but still functional fallback layout is an acceptable tradeoff.
The specific thing that pushed us over the line was rebuilding a client's card-based product grid, three or four cards per row that needed to stay equal height regardless of how much copy went into each one's description, something we'd have solved with a JavaScript height-matching script as recently as last year. Flexbox's align-items: stretch handled it with zero JavaScript and no risk of a flash of unstyled height before a script ran, which is exactly the kind of small, previously-annoying problem this spec seems built to solve.
We're still writing a documented fallback for the handful of client sites where analytics show a meaningfully larger population of older browsers, mostly older enterprise clients whose own customers are on locked-down corporate machines, and treating flexbox adoption as a per-project decision informed by that specific project's actual traffic rather than a blanket rule applied everywhere regardless of audience.
Worth revisiting old assumptions periodically. Something that wasn't ready two years ago often is now, and the discipline of actually rechecking browser support numbers rather than relying on a two-year-old impression is probably the more generally useful habit here than flexbox itself.
We also went back and quietly retrofitted flexbox into a couple of existing client sites during routine maintenance windows, not because anything was broken, but because the float-based layout underneath had accumulated enough small hacks over time that replacing it outright with a flex container removed more fragile code than it added. That's a genuinely different kind of adoption than using it on new builds, retrofitting into a live site carries real risk of a subtle visual regression a client notices before we do, so we've limited it to sites where we have a good visual regression testing habit already in place, comparing screenshots before and after rather than trusting a manual once-over alone.