The Anatomy of a Layout Nightmare

For decades, web designers have wrestled with the fact that centering a <div> is still a puzzle. The CSS box model, with its padding, border, margin, and content boxes, is a series of rules that, when combined with the peculiarities of text alignment, floats, and inline formatting, can produce layouts that are hard to predict and even harder to debug.

“If a container b has text-align: center specified, then its left gap equals its right gap… If the container is too small to contain the content, we left‑align it no matter what.” – formal semantics of CSS 2.2

This tiny excerpt from Pav Panchekha’s formal semantics shows how a seemingly innocuous rule can carry a hidden edge‑case that designers have to remember: a centered block that overflows on the left is automatically left‑aligned to avoid content spilling off‑screen.

The Promise and Peril of Constraint‑Based Layout

A natural idea is to replace the rule‑based cascade with a constraint system: authors write declarative constraints, and a solver computes positions and sizes.

• Cassowary – the incremental solver used by iOS’s Auto Layout – can quickly re‑solve constraints when a page changes.
• LaTeX – a long‑standing example of constraint‑based typesetting – demonstrates that even with a formal system, designers still need to tweak weights and optimization criteria to avoid over‑ or under‑determined layouts.

However, the same flexibility that makes constraint solvers powerful also makes them fragile. A single missing constraint (e.g., “set the parent’s width to the minimum required to contain the child”) can leave a layout under‑determined, while an excessive set of constraints can make it over‑determined and force the solver to break rules arbitrarily.

"Writing layout constraints for UIs that aren't either under‑ or over‑determined is basically impossible." – Panchekha

The result is a system that is both verbose and brittle, with debugging becoming a tedious exercise in balancing implicit rules, optimization criteria, and weight assignments.

Why Edge Cases Are Inevitable

A layout system must adapt to a host of variables: screen size, zoom level, font rendering differences between Windows and macOS, device notches, translations, and even new features that change content size. The CSS designers, aware of these realities, embedded implicit knowledge into the spec:

• Text justification that expands spaces when a line is too narrow.
• Hyphenation and letter‑spacing as fallbacks.
• The left‑align fallback for overflowed centered text.

These rules stem from centuries of typesetting tradition—think of newspaper columns that were always narrow, so editors would rephrase text to avoid ugly justification. Modern CSS inherits this legacy, which is why designers still encounter surprising edge cases.

The Pragmatic Shift: Flexbox and Grid

Rather than reinvent the wheel, the CSS Working Group has introduced new layout modes that target specific use‑cases:

• Flexbox – great for one‑dimensional layouts (rows or columns) with intuitive alignment and distribution properties.
• Grid – a two‑dimensional system that handles complex page structures with declarative row/column definitions.

These modes are more intuitive once the mental model is understood, and they expose fewer edge cases than the legacy flow layout. They also allow designers to express common patterns (e.g., equal‑height columns, centered content) with fewer lines of CSS.

"The solution is what the CSS committee has been doing: standardizing new and more intuitive layout modes optimized for the specific types of layouts." – Panchekha

Takeaway

CSS layout is hard not because of a single bug but because of the sheer number of variables a page must accommodate. Constraint‑based systems offer a clean theoretical framework but fall short in practice due to under‑/over‑determination and the need for implicit heuristics. The industry’s gradual adoption of Flexbox and Grid reflects a pragmatic compromise: keep the cascade but replace the most problematic primitives with well‑understood, low‑edge‑case alternatives.

By embracing these newer modes—and by continuing to refine the implicit rules that govern them—developers can build responsive, maintainable UIs without drowning in layout quirks.

*Source: Pav Panchekha, "Why CSS is Bad" (https://pavpanchekha.com/blog/why-css-bad.html)