Firefox.com rebuilt in native CSS with no preprocessors, closing the CSS Zen Garden gap

Firefox.com rebuilt in plain, native CSS

Firefox.com, Mozilla's flagship product site, has been rebuilt with a styling system written entirely in modern, native CSS — no Sass, no preprocessor dialects — according to Jo Sprague, the developer who led the work alongside Mozilla and the agency Lincoln Loop. In a blog post titled “The CSS Zen Garden dream, finally shipped” that reached the front page of Hacker News, Sprague frames the rebuild as the arrival of a two-decade-old promise: the strict separation of content from presentation that Dave Shea's CSS Zen Garden once demonstrated.

The dream that fell apart in production

Sprague recounts discovering the Zen Garden in 2008, shortly after graduating. The project showed a single HTML file restyled into something completely different using nothing but CSS — and that was exactly where reality diverged. Browsers of the era had no CSS variables, the available properties could not express a full design, and practitioners fell back on server-side processing, images, table layouts and hack after hack, with much of the effort spent making a single design behave across every browser. The Zen Garden proved what was possible in theory; shipping client work was another story, Sprague writes.

Closing that gap took the better part of two decades, and Sprague attributes most of the progress to the past few years: custom properties gave browsers variables they actually understand, Grid and Flexbox delivered layout systems suited to the medium, and the once-missing properties now exist and are implemented consistently enough that designers can build against them instead of around them.

What the rebuild shipped

On Firefox.com, the team delivered a design system of more than 70 components and 25 page templates, implemented as Wagtail components so the site's content team can assemble pages without engineering help. The site currently supports 19 locales. Custom properties are exported directly from the design files, the styles are authored a single time without browser hacks, and every modern browser receives the full experience. Legacy browsers get a minimal branded stylesheet that keeps the site usable and accessible.

One honest footnote: PostCSS survives

Sprague is candid that one build tool remains: PostCSS runs in production solely to inline @import statements, because native @import performs poorly in some browsers, and a site at this scale cannot sacrifice speed for purity of approach. That distinction, Sprague argues, is what should define any “no build step” claim. The authored CSS is plain and stands on its own — nothing in it needs a build to be valid or to make sense — and the build step merely flattens files the browser would otherwise fetch one after another. The real test is whether the code you write is the browser's own language, or a dialect that disappears at compile time.

Why it matters

Firefox.com is a site about a browser, built by an organization that has championed the open web for 20 years — which Sprague calls about the best proving ground imaginable for whether the platform is genuinely ready. The project suggests the practical justifications for preprocessors have largely evaporated: variables, theming and robust layout are now platform features, and a designer's decisions can reach production without being translated repeatedly along the way. Sprague also credits the wider community — naming Nicole Sullivan, Rachel Andrew, Jen Simmons, Chris Coyier and Eric Meyer — with teaching a generation to treat CSS as a system rather than a pile of overrides. For teams weighing a front-end rebuild, the lesson is not that tooling is obsolete; PostCSS still earns its keep for one performance fix. It is that the source of truth can now be standard CSS, understood natively by every modern browser.