DEV Community: Stéphane LaFlèche

We're making the Dreamweaver mistake again, on purpose this time

Stéphane LaFlèche — Wed, 24 Jun 2026 20:37:51 +0000

We spent twenty years getting designers out of the code. AI just put the design back in charge of it.

The pendulum swings back

Designers used to be in the code. In the Dreamweaver and WYSIWYG era, you laid out a page in a visual tool and it wrote the markup for you. The industry then spent the better part of twenty years undoing that. We drew a line: designers design, developers build, and a human translates between the two.

AI is swinging the pendulum back. Not by putting designers back in the code, but by handing their design to a machine that writes it. Point the model at the file, get components out. The design drives the code again.

Here is the part that should give you pause. This is not a clean return to the Dreamweaver days. Back then, however messy the generated markup was, a person still sat in the translation and owned it. Now the design goes straight to code with no one in the driver's seat. That seat is where quality used to get enforced.

Two quick things before I go further, because this argument gets misread in two predictable ways.

First, this is not a knock on designers. Designers do great work. The point is a distinction. What makes a great design file is not what makes a great design system, or what makes good code. A file is judged on the design. A system is judged on reuse, on states, on durability. The AI workflow blurs that line, and the blur is the whole subject.

Second, if you are building a simple static site, pointing AI at the design is genuinely fine. The snapshot is the thing. Ship it. The problem I am describing only bites when the design is meant to become a reusable system: a design system, a custom CMS, a dynamic UI. Keep that scope in mind.

The dream is real

I want to be fair to the dream, because it is seductive and it is partly true. Point AI at the design, get working code, one step.

AI is genuinely valuable. I use it. It has let me do things I could not have done before, and finish projects under tight deadlines in codebases I did not know well. I am not here to tell you the tool is bad.

But notice where that value lands. It lands at the snapshot level. Real value is not the same thing as a foundation. That gap is the rest of this post.

A design is not a foundation

Here is the concrete failure, and it is not hypothetical. Teams build entire token pipelines around the variable names a designer chose in Figma. Naming is a design decision, but auto-translation quietly promotes it to a load-bearing contract. Rename one variable in the design file and the pipeline snaps three steps downstream. The design is doing a foundation's job, and breaking, because it was never built for it.

You can see it in a single pair of names. --blue-500 is a value; --color-primary is an intent. A system should depend on the intent, and AI cannot reliably tell which one the design meant.

The obvious fix is to train designers to name things the system-correct way. But that points the effort at the wrong person. I love working with designers, but the answer is not to turn them into systems engineers, negotiating every token name. Translating their vision into a durable system is my job, not theirs. That translation wants to be a pipeline: map the design tokens onto a universal standard, then watch for drift. I will come back to what that standard is.

Naming is only the first failure mode. Set it aside and a deeper one remains. A design is a static snapshot. It shows one state of one screen. It does not encode reusable versus one-off, the empty, loading, and error states, what is content-driven versus fixed, or how a CMS feeds it. That systemic context lives in the developer's head and in the code. It is not in the file.

The industry has noticed the input problem, and it is moving on it. Google recently open-sourced DESIGN.md, a format for handing a structured design system to a coding agent instead of a raw file, and a catalogue of them is already forming.¹ That is a real step, and it tells you the input was a weak link all along. Hold that thought, because where DESIGN.md stops is exactly the point.

The deeper limit is not the input format. It is that the design, in any form, is the wrong source for the decisions. The model's best case is the guts of the design file, an artifact optimized for none of the things a foundation needs: not design-system structure, not coding best practices, not the developer or agent experience. Its worst case is a screenshot, pixels with no structure at all. Even a flawless extraction cannot supply the architectural decisions a human makes to accommodate a design.² The deciding stays human.

So the verdict. A design is not a foundation. Auto-translating it into code silently promotes it to one, and it was never built for the role.

People are working on this

This gap is real, and a lot of people are working on it right now, from the biggest players to solo builders. Google's DESIGN.md is one move. An ecosystem has formed around it almost overnight, and it is already being put to the test in production. My friend Amrutha Kollu is one of the independent builders coming at it. Her tool, Fixel, validates your code against Figma in continuous integration and catches design-system drift before it merges. When it finds drift, it posts the finding back onto the Figma canvas as a comment, so the designer sees it in the place they already work.³ It is promising work on a real problem.

Where all of this lands is genuinely open. A lot of smart people are coming at the same problem from different angles at once. That open question is the honest state of things, and it is a big part of why I am writing this.

I want to be precise about where it sits, because the boundaries are the interesting part. Fixel is on the code side, and it does not claim to have solved the whole thing. The limit worth naming, and I mean it as architecture, not criticism: it reads directly from the design tool, so any tool-coupled approach risks going obsolete unless it targets the open standard underneath. That standard is the W3C Design Tokens format, or DTCG, the vendor-neutral spec the major tools are converging on, and it is the durable anchor here.

The missing middle

You might think the newest tools already close this. They have gone well past reading a screenshot. Claude Design imports your design system straight from your codebase and checks its output against it before you see it.⁴ Google's Stitch reads your tokens before it draws a screen. That is real, and it is the convert step getting genuinely good.

But two things none of it does. It assumes the system already exists and is clean enough to import, which means someone built that foundation and still owns it. It also checks only once, at generation. The harder problem is what happens after the code merges, when the design and the system keep moving and quietly drift apart.

So that is where this leaves us. Not with the design driving the code, and not with a person hand-translating every screen either. It leaves us with a middle that someone has to own.

Here is the bet I would make on what the missing middle looks like. I think it starts with typed CSS inputs at build time: a foundation where a value carries a type and a meaning, not just a string the model can get wrong. On top of that, the AI does what it is good at. It pulls the variables out of the design and proposes how they map onto the system you already have. Then the UX engineer does what only they can. They shape that proposal into the system they actually want, decide what each value means, and set the behaviour and the success criteria the result has to meet. Typed inputs and automated checks keep the AI's suggestions honest.

Those decisions do not live in someone's head, or get re-derived on every run. They become an artifact: a committed, versioned record of how this design maps onto the system, owned by the engineer. Fixel already does a version of this. Its overrides registry commits each intentional deviation to git with a reason and a timestamp, an audit trail instead of a silent guess. This is the part DESIGN.md cannot reach. Its prose "why" is re-read and re-interpreted by the model on every run, where a committed artifact is a decision someone made and signed.

Notice what did not happen there. The design never became the system on its own. Clean variables out of Figma are a real step, but they are not the finish line, because the same tokens can be implemented a hundred ways. Choosing which one is the judgment, and the judgment is the job.

The mistake, named

Here is the irony to leave on. AI makes designers more responsible for code quality than they were back when we actually wanted them writing it. The design becomes the code, and no one is left gatekeeping the translation.

So the real mistake is not that we use AI to get there. It is that we are writing the UX engineer out of the loop, right when that judgment most needs an owner. The role is not going away. It is changing into the person who owns this middle: the system the design feeds into, the mapping, the contract that keeps a design from quietly becoming the foundation.

The durable anchor under all of it is a standard with the mapping in your hands, and that standard is where I am headed in my next article.

If you are building this middle, I would genuinely like to hear how you draw the line between what the AI proposes and what stays yours to decide. That is the conversation I am trying to start.

DESIGN.md is a Markdown file that describes a design system to an AI coding agent in a structured way: machine-readable tokens plus human-readable prose. Google Labs open-sourced it in April 2026. See the Google Labs announcement (blog.google, "Stitch DESIGN.md") and the spec repo (github.com/google-labs-code/design.md). A community catalogue at getdesign.md (maintained by VoltAgent) already lists 75 DESIGN.md files built on the spec (as of June 2026). ↩
This limit shows up in practice. When Atlassian benchmarked DESIGN.md against their own design-system tooling, they reported it was more likely to re-create existing components than to import the ones already in their system. A faithful description of how a component looks does not carry the decision to reuse the component that already exists. See Atlassian, "Atlassian's DESIGN.md is here: what we learned testing portable design context in practice" (atlassian.com, June 2026). ↩
Amrutha Kollu's writing on this gap: How I shipped 60+ design system components in 5 weeks using Figma as the single source of truth, Why AI keeps generating the wrong design tokens and how I fixed it with Figma's API, and Check Designs validates your Figma. What validates your code?. Fixel validates code against Figma in CI to catch design-system drift. ↩
Claude Design, Anthropic Labs (anthropic.com/news/claude-design-anthropic-labs). A June 2026 update added importing a design system from a repository or files and checking generated output against it. ↩

Most of the web is touch. We still don't save handedness.

Stéphane LaFlèche — Fri, 19 Jun 2026 01:02:51 +0000

How is there still no OS setting to save your handedness preference?

We can detect a surprising amount about how someone wants to use a page. Dark mode, reduced motion, higher contrast, reduced data: the prefers-* media features expose all of it. There is one obvious preference the platform never exposes: which hand you are using.

On a touchscreen, your hand is the interface. It is the cursor. Yet a designer building for that screen has no way to know whether the thumb in play is on the left or the right. So I opened a proposal with the CSS Working Group for a new media feature:

@media (prefers-handedness: left) {
  /* layout tuned for a left thumb */
}

@media (prefers-handedness: right) {
  /* layout tuned for a right thumb */
}

Like the rest of the family, this is a declared preference, not a guess about your body: the user sets it the way they set dark mode. And because it would live at the OS level, flipping it could be a one-tap control, the same quick toggle we already use for things like Bluetooth. The web already reflows an entire layout when you rotate the screen, so a left-to-right flip is a smaller version of a shift the platform has handled for years.

Here is why I think it earns a place in the family.

The case

Most of the web is touch now

Touch is no longer the secondary surface. As of Statcounter's May 2026 figures¹, mobile sits at 50.29% of global page views and tablets add another 1.48%. Phones alone have edged past desktop. The majority of the web now happens on a screen you hold in one hand and drive with the other.

And about 1 in 10 of those users are left-handed

The best estimate from the largest meta-analysis of handedness², 200 studies and over 2.3 million people, is that roughly 10% of people are left-handed. Stack that on top of a touch-majority web and you get a real population, not an edge case: a tenth of the dominant surface, using it the mirror image of how it was likely designed.

Apps already solve it, one at a time

This is not hypothetical. Creative apps already ship handedness settings by hand. Procreate has a Right-hand interface preference³ that flips its sidebar, because the default sits under the left hand while you paint with the right. SketchUp for iPad has a left-handed mode. Note apps tune palm rejection around which hand is resting on the glass. The mechanic differs (occlusion on a tablet, reach on a phone), but the missing signal is the same, and any of these apps could take its default straight from the OS instead of asking again.

Every one of these reinvented the same toggle, because the platform exposes no shared signal. That is the argument for standardizing one: a user should set this once and have everything honour it, not hunt for the same preference in every app. It is the same reason dark mode lives at the OS level instead of in a hundred separate settings screens.

It's a UX choice, and it goes beyond placement

Not just flipping the menu

To be clear, this is not "put the menu on the left." Designers already place navigation on either side freely, and both are fine. Which hand is holding the device is a different thing: a deliberate decision about what sits where, and that map depends on the hand. On a phone it is reach: a primary action belongs under the resting thumb, and a destructive action is often placed out of easy reach on purpose so it is hard to hit by accident. On a tablet it is occlusion: the dominant hand and forearm rest over the screen, so a control on the wrong side ends up under the very hand that is covering it. Without a handedness signal, that intent silently inverts for left-handers: the action you tucked away becomes the easiest one to hit, and the content you meant to keep clear sits under their hand. You never know it happened.

Gestures and interaction, not just layout

It also reaches past static layout. prefers-* features are readable from JavaScript through window.matchMedia, so handedness would drive interaction, not only styling:

const leftHanded = window.matchMedia("(prefers-handedness: left)").matches;

That opens up things CSS alone cannot reach: inverting a swipe or gesture direction, choosing which edge a swipe action lives on, deciding where a context menu opens so the hand does not cover it. This is an interaction signal, not a styling toggle.

The objections

"Too niche, too much work"

The feature itself is trivial: a single value a stylesheet or a script can read. The family already includes prefers-reduced-motion, which is more involved both to define and to honour, and it shipped. Dark mode is the cleaner precedent. prefers-color-scheme went from nothing to shipping across every major browser by early 2020⁴, fast, and it is arguably a more frivolous preference than how you physically hold the device. It is low-hanging fruit: easy to implement, and a real improvement for a substantial share of users. Hard to beat that return on effort.

"It needs platform buy-in"

True, and that is the point of proposing it as a standard. The signal would be an OS setting, the same origin as dark mode. Both prefers-color-scheme and prefers-reduced-motion needed operating systems to expose a setting, and both got it. Handedness only differs in that the toggle does not exist yet. The honest part: that is a heavier ask than a normal CSS feature, because it needs device makers, not just browsers. But the incentive is there. Handedness support is a real selling point on phones and tablets, and the stylus world already tracks it for palm rejection. The people who would benefit from shipping it are the same people who would ship it.

"It's a fingerprinting vector"

This is the serious objection, and it was the first thing raised on the proposal. The answer is to scope it. Handedness is meaningless on desktop, where the pointer is decoupled from grip, so the query can carry a value only in touch contexts and add no entropy where it would be useless anyway. And because it is a declared preference that ships off by default, like the rest of the family, it is a single low-entropy bit the user controls, not something inferred behind their back. It can also be restricted to first-party contexts, so the page you are visiting can read it but embedded third-party scripts cannot. That closes the cross-site tracking path without an opt-out checkbox or a permission prompt.

Weigh in

The proposal is live and open. If you have a use case, a concern, or a good argument against it, that is exactly what the thread is for: csswg-drafts #13215.

And if you think this should exist, say so there. A thumbs-up or a short comment with your own use case is the kind of signal that helps a working group tell a real need from a passing idea.

Statcounter Global Stats, Desktop vs Mobile vs Tablet Market Share Worldwide, May 2026: https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet ↩
Papadatou-Pastou et al. (2020), Human handedness: A meta-analysis, Psychological Bulletin: https://doi.org/10.1037/bul0000229 ↩
Procreate Handbook, Interface (Right-hand interface preference): https://help.procreate.com/procreate/handbook/interface-gestures/interface ↩
MDN, prefers-color-scheme (Baseline since early 2020): https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme ↩

The case for compiled, typed CSS (blame AI)

Stéphane LaFlèche — Wed, 27 May 2026 10:38:44 +0000

We spent years getting TypeScript to where it is. It already checks your APIs, your components, your state. Your CSS values are still strings that nothing compiles. Why wait for a new tool when the one you have can do this today?

A 2025 academic study ^[1] found that 94% of LLM-generated compilation errors were type-check failures. GitHub's Octoverse report ^[2] cited the same stat to explain TypeScript's rise to the most-used language on the platform. In typed languages, the compiler catches most of what AI gets wrong. CSS has no compiler.

Two claims follow, and they're separable. First: CSS lacks a verification layer, and AI makes that gap expensive. Second: build-time typed styles are the fix I've landed on. TypeScript is already in the stack. Anything else is another dependency and another source of drift. You can accept the first claim and argue with the second.

AI fails at CSS

Write var(--spacign-md) and nothing fails. The browser silently falls back. Write padding: 12px when your design token says 16px. It renders. Ship it.

AI has generated width: fit-parent ^[3], a value that does not exist (the real one is fit-content). It writes padding: 12px when the design token is spacing-md at 16px ^[4], because it doesn't check your token file, it approximates. It applies Tailwind v3 logic to v4 projects ^[5], importing deprecated packages and breaking styles. As one writer put it: "AI didn't create this problem. It scaled it." ^[4]

Human developers hesitate when uncertain. AI does not. It generates code with the same confidence whether implementing a known pattern or hallucinating something that has never existed ^[3].

Linters like PostCSS and Stylelint catch syntax errors, not semantic ones. They verify grammar. What's missing is something that verifies meaning. And yes, AI writes better plain CSS than CSS-in-JS: more training data. But better unchecked CSS is still unchecked.

"AI will just get better"

Maybe. But we still need to ship code today.

Web-Bench ^[6] (ByteDance, 2025), a benchmark of real-world web development tasks, showed the then-leading model (Claude 3.7 Sonnet) at 25.1% first-pass accuracy. GitClear's 2025 analysis ^[7] of 211 million changed lines (2020-2024) found copy-pasted code rose from 8.3% to 12.3% while refactoring collapsed from 25% to under 10%. The benchmark scores go up. The real-world quality metrics go the other direction.

Simon Willison argued ^[8] that code hallucinations are the least dangerous kind, because compilers catch them. He's right, except CSS has no compiler. His optimism has a CSS-shaped hole.

"AI will get better" is a bet. A type system is a guarantee.

Where Tailwind stands

Tailwind is dominant for new projects at ~12 million weekly downloads ^[9]. Its LSP flags invalid classes, ESLint plugins enforce scale usage.

But Tailwind v4 moved configuration from JavaScript (tailwind.config.ts) to native CSS (@theme {} blocks). Simpler, yes. But the default path now authors tokens directly as CSS strings, outside any type system. You can still generate @theme from a typed source, that is exactly the move I'll argue for below, but nothing in v4 pushes you there. The path of least resistance lost its types. If AI writes @theme { --color-brand: #3b82f6 } when the designer specified #2563eb, the CSS build passes fine. Both are valid hex. The problem isn't syntax, it's that there's no contract between your styles and your TypeScript components. Meanwhile, Tailwind Labs itself is under AI pressure: revenue down 80%, three engineers laid off ^[10]. The framework thrives while the company scrambles. AI is reshaping even the most popular CSS framework's ecosystem in ways nobody planned for.

Build-time typed styles

Not runtime CSS-in-JS. styled-components, Emotion, runtime style injection: that's dead for good reasons ^[11], and it should stay dead.

This is something different. Values live in TypeScript, get checked by the compiler, and emit static CSS. Zero runtime. The output is plain CSS. The verification happens before it reaches the browser. The AI has to satisfy the TypeScript spec to produce output at all.

You can write custom validation on top: assert that a color pair meets contrast requirements, that a measurement doesn't exceed a bound. If your values already live in TypeScript, why maintain a parallel set in Sass?

Why maintain two sets of values?

TypeScript is the most-used language on GitHub ^[2] as of August 2025. Your spacing scale, your breakpoints, your theme config: they're already in .ts files.

The question isn't "should I put CSS in JavaScript?" It's "should I type the values that are already there?"

If you maintain CSS variables separately from your TypeScript tokens, you have two sets of values to keep in sync. That's where drift creeps in. Define your tokens once in TS, output to CSS variables, a Tailwind theme, responsive helpers, whatever your project needs. One source, no sync problem.

CSS variables are great. They're not a contract.

I used to dismiss CSS variables. Then I found a real use for them: responsive values from Figma design tokens that replaced a React context for window sizes. Huge simplification. I'm strict about keeping usage limited to where they genuinely earn it.

But CSS variables have specific weaknesses with AI. var(--spacign-md) is valid syntax that silently fails. When a variable is set at the root, overridden in a layout component, overridden again in a card, and consumed in a button several layers deep, AI has no way to reason about which level set it. @property adds native type checking, but it validates at render time, not build time. The wrong value still ships. Going the other direction, reading CSS vars in JavaScript with getComputedStyle is runtime string parsing. No type safety going in, no type safety coming out.

And native CSS features always lag behind in browser support. When your values live in TypeScript and compile to static CSS, you control the output. Browser compatibility becomes a build concern, not an architecture concern.

You can still output CSS variables from your typed tokens. That's not a tradeoff, it's the point. One typed source, visible to both CSS at runtime and TypeScript at build time.

Verification, not authoring

The argument is about verification, not authoring. AI made authoring effortless: it produces CSS as fast as you can ask for it. Producing correct CSS is a different problem, and nobody solved the checking part. "Design systems solve the vocabulary problem. They do not solve the verification problem." ^[4] Types are the verification layer.

The strongest counter is "just give AI better context." It's partially right. Sachin Patel's team ^[12] aligned Figma tokens with CSS variables and got reliable output. I use context engineering myself: I've written Claude Code skills and Cursor rules to keep AI aligned with codebase standards. These approaches work.

But context is a conversation. The next developer, or the next AI session without the rules loaded, can ignore it. Types are a contract. You can't compile past them. Or as a Builder.io blog post ^[13] framed it: "Without types, the AI is guessing. With types, it's reading a spec."

Off-scale is fine, as long as it's visible. An explicit m(17) is different from a magic p-[17px] buried in a Tailwind class string. And because it's structurally distinct, you can lint for it. A CI rule that flags off-scale density is trivial when escape hatches have their own syntax. When off-scale and on-scale look identical, that rule is impossible.

In practice, visual regression testing, human review, checking layouts across viewports: that work exists whether you use typed styles or not. What typed styles change is what you spend your review time on. Without them, reviewers catch both mechanical errors and visual ones. With them, the mechanical layer is handled before the code reaches review. What's left is the judgment work. There's a taxonomist quality to writing good CSS: classifying values, deciding where things belong. That part stays human. Types clear the noise so you can focus on it.

I've been building the typed-measurement piece of this with CSS-Calipers. That layer is solid: compile-time unit safety, immutable values, off-scale values that are explicit rather than invisible. The broader framework around it is not solved, and I'm not claiming it is.

Use what your project needs

This is not an all-or-nothing proposition. Nobody is asking you to rewrite your project in CSS-in-JS. Maybe you type your entire spacing scale. Maybe you type one mission-critical token that keeps breaking. Maybe you don't need any of this. You know your project best.

I'm resistant to change myself. I had a visceral reaction to CSS-in-JS when I first encountered it. Had the same reaction to CSS variables. Both times, a specific use case changed my mind. Not hype. A real problem the tool solved better than the alternatives.

The industry was right to leave runtime CSS-in-JS. Native CSS is more powerful than ever. Tailwind dominates for real reasons. The point isn't to replace any of that. It's that a verification layer should exist for the parts that matter, and you should know the tradeoff when you skip it.

The output is still the full CSS spec. Nothing is restricted. What changes is how many guardrails you put between your values and that output. One project might need strict token enforcement across every component. Another might need a single typed measurement in a critical layout. The point is you choose the constraint level, not the framework.

CSS should fail silently in the browser. That's a feature. It should fail loudly in the build. That's what's missing. I wrote about what a real CSS framework could look like if you want the longer version of that argument.

References

[1] Mündler et al., "Type-Constrained Code Generation with Language Models" (2025) - https://arxiv.org/abs/2504.09246
[2] GitHub Octoverse 2025 - https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/
[3] Shahid Pattani, "Design-to-Code AI Is Not Magic" - https://medium.com/aimonks/design-to-code-ai-is-not-magic-heres-why-it-fails-sometimes-7740051f3580
[4] Emilia BiblioKit, "3 Design System Bugs That Survive Every Code Review" - https://medium.com/design-bootcamp/3-design-system-bugs-that-survive-every-code-review-and-why-ai-makes-them-worse-55272372ee6a
[5] Prathit, "AI Models Still Can't Configure Tailwind Correctly" - https://prathit.vercel.app/blog/ai-models-still-can%27t-configure-tailwind
[6] Web-Bench (ByteDance, 2025) - https://arxiv.org/html/2505.07473v1
[7] GitClear, "AI Code Quality 2025" - https://www.gitclear.com/ai_assistant_code_quality_2025_research
[8] Simon Willison, "Hallucinations in code are the least dangerous form of LLM mistakes" - https://simonwillison.net/2025/Mar/2/hallucinations-in-code/
[9] PkgPulse, "The State of CSS-in-JS in 2026" - https://www.pkgpulse.com/guides/state-of-css-in-js-2026
[10] devclass, "Tailwind Labs layoffs" - https://devclass.com/2026/01/08/tailwind-labs-lays-off-75-percent-of-its-engineers-thanks-to-brutal-impact-of-ai/
[11] React 18 Working Group Discussion #110 (Sebastian Markbage) - https://github.com/reactwg/react-18/discussions/110
[12] Sachin Patel, "Cursor Isn't the Problem. Your Design Tokens Are." - https://medium.com/@sachin88/how-we-fixed-design-tokens-to-make-cursor-generate-reliable-ui-code-74d699e72e38
[13] Builder.io, "TypeScript vs JavaScript: Why AI Coding Tools Work Better with TypeScript" - https://www.builder.io/blog/typescript-vs-javascript

We still don't have proper CSS frameworks

Stéphane LaFlèche — Fri, 22 May 2026 12:58:55 +0000

We have utility libraries, class-naming conventions, and methodologies dressed up in framework branding. What we don't have is a CSS layer that behaves like a framework does in any other ecosystem: typed input, defined output, a contract a compiler can actually enforce.

This is the long version of a complaint I've been making in private for years. It also names what I think a real CSS framework would do, and shows the working sketch I've been building in that direction.

Tailwind is useful, but it's not really a framework

The current heavyweight is Tailwind, with over 400 million npm downloads a month as of May 2026, so let's start with what it actually is. Strip the build step away and the utility-first methodology isn't new. Object-Oriented CSS, popularized by Nicole Sullivan in 2008, was already making the same case: small, single-purpose classes you compose at the markup layer.

Before Tailwind existed, plenty of teams generated their own utility scales using SCSS loops. You can rebuild a meaningful slice of Tailwind's spacing utilities in a few lines of SCSS that would've worked in 2012:

// Define the design system tokens
$spacing-map: (
  "1": 0.25rem, // 4px
  "2": 0.5rem,  // 8px
  "4": 1rem,    // 16px
  "8": 2rem     // 32px
);

// Loop to generate padding and margin utilities
@each $key, $value in $spacing-map {
  .p-#{$key}  { padding: $value; }
  .pt-#{$key} { padding-top: $value; }
  .m-#{$key}  { margin: $value; }
  .mt-#{$key} { margin-top: $value; }
}

// Compiles to:
// .p-1  { padding: 0.25rem; }
// .pt-1 { padding-top: 0.25rem; } ...

What Tailwind genuinely adds is the build step. The JIT compiler scans your codebase and emits only the utility classes you actually use, with arbitrary-value support (p-[17px]) for one-offs. That's a real ergonomic win. Bundle sizes shrank and authoring speed went up.

The downstream cost is harder to talk about, because it shows up in maintenance, not authoring. In a Tailwind codebase, when something looks off on a page and you go searching for what styled it, you often can't. The class you'd search for (flex, text-center, p-4) appears a thousand times across the project. Layout decisions become string fragments scattered across every component file, not declarations you can grep, jump-to, or rename in one place. The tools that normally help you navigate a codebase mostly don't.

What we have, then: utility classes that were doable in SCSS in 2012, a build step that makes them ergonomic, and a search-and-rename problem that gets worse the bigger the project gets. Is that really what we want from a framework?

Where this breaks

AI didn't break Tailwind, even though January's layoffs at Tailwind Labs (the "AI killed Tailwind" framing) read that way in headlines. It exposed a contract Tailwind never had.

For most of the Tailwind era, humans wrote the class names. There was an implicit social contract: you stayed mostly on the spacing scale, you didn't use arbitrary values without a reason, you noticed when a string was getting absurd and broke it into a component. The framework didn't enforce any of that. It just trusted you.

The trust assumption is breaking. AI now writes a meaningful share of production CSS, and AI has no implicit social contract. It generates plausible-looking utility strings that pass a glance review and then break across a viewport, or duplicate themselves, or quietly drift off the scale. The class attribute runs to thirty utilities, half of them redundant (p-4 pt-4 pb-4 px-4 mt-2 mb-2 for what should have been p-4 my-2), and nothing in the stack catches the drift. Reviewing the output by hand becomes the bottleneck.

The arbitrary-value escape hatch. p-[17px] was tolerable when a senior dev would push back in review. Now it's a default behavior of the code generator, and there's no contract for anyone to point at. "Use the scale" is a vibe, not a rule.

The systematic-looking string. p-[var(--spacing-3)] looks systematic. There's a token name in there, the convention seems followed, reviewers wave it through. But the framework's scanning step doesn't actually understand it. The var lives inside a string fragment, not in the helper API. You can typo the variable name and ship it. Nothing catches that. Hardcoding is honest dishonesty. Token-wrapped strings are dishonest dishonesty.

Tailwind users will point to the fixes: @apply and component extraction for the grep problem, ESLint plugins and a theme-only config for the off-scale problem. These help, but they are external constraints layered on top, not a contract the type system enforces. A linter you can disable per line is a convention with tooling, not a compiler that refuses to emit invalid output. That distinction is the whole argument.

The fix isn't to ban AI from CSS, or to ban arbitrary values. The fix is to give the codebase a contract the AI can actually run inside: typed inputs that the build can verify, helpers that emit valid CSS, off-scale values visible rather than indistinguishable from on-scale ones.

What a framework should mean for CSS

In any other ecosystem, a framework gives you a contract. You hand it inputs in a defined shape, it does the work inside, you get a defined output. Rails takes route definitions and gives you a request lifecycle. React takes components and props and gives you a reconciled tree. The framework owns the implementation; you own the configuration and composition.

A CSS framework, by that standard, would:

Take typed design tokens in and emit valid CSS out. Every value (length, color, string) becomes data the build can see, not strings to scan.
Fail at compile time on mismatched units. Off-scale values stay possible, but visibly off-scale, not laundered into the same syntax as everything else.
Cover the full CSS spec, not a subset. New properties land in browsers all the time (@container, view-timeline, field-sizing); a framework that gates which features you can use restricts the work to whatever its authors had time to model.
Stay opinionated at the edges, loose in the middle. Strict on typed input and valid emission. Composition, file organization, helper depth: all yours.
Offer opt-in helpers, never mandatory ones. A team could write a borders helper that groups width, color, and radius the way designers think about them; another team could skip that layer entirely.

That shape (strict edges, loose middle, full spec) is the inverse of how most CSS frameworks work. Tailwind owns the middle (every class is theirs); the edges stay loose (any string can land in a class attribute). CSS-in-JS libraries own a template syntax in the middle, with values inside the template still untyped. Typed CSS-in-JS libraries like vanilla-extract type the output but not the input. A framework with strict edges in both directions, and a loose middle, is rare in CSS, but it's how typed systems work everywhere else.

A working sketch: CSS-Calipers

This is the principle in code. CSS-Calipers is a small TypeScript library I wrote last year. The ideas behind it go back to my Vanilla Forums days. It covers the measurement-and-math piece of the framework I keep wanting. Tokens in, typed CSS out. The helpers are the contract. Best to use at build time, but occasional runtime possible.

The measurements stay opaque through composition. Nothing emits a string until you call .css() at the boundary. The math is checked at every step, not just at the end.

Mismatched units fail fast. As the snippet above shows, paddingBase.add(rotation) throws a clear error with px vs. deg named in the message. You don't find out in production that you added pixels to degrees.

The measurement core is the foundation. On top of it I've built a helpers layer in my portfolio: borders, paddings, margins, shadows. Each helper consumes measurements and emits typed style objects. Here's the borders helper in actual use:

// Use defaults from the token layer
export const cardBase = style(borders());

// Override specific values inline
export const cardEmphasis = style({
  ...borders({
    width: m(2),
    radius: { south: m(8) },  // compass-style: south = bottom
  }),
});

// Or pass a full token config
export const cardThemed = style({
  ...borders(theme.cardBorders),
});

Three calling shapes, all valid: defaults, inline overrides, full token configs. The third one is where this starts to feel like a framework. Imagine you import the token from a tokens file:

// tokens/cardBorders.ts — today
export const cardBorders = {
  width: m(1),
  color: theme.colors.surface,
};

// components/Card.styles.ts
import { cardBorders } from "@/tokens/cardBorders";

export const cardStyles = style({
  ...borders(cardBorders),
});

Now design wants a thicker accent top and rounded bottom corners. You edit only the tokens file:

// tokens/cardBorders.ts — after the design tweak
export const cardBorders = {
  width: m(1),
  color: theme.colors.surface,
  top:    { width: m(3), color: theme.colors.accent },
  radius: { south: m(8) },
};

The component file is unchanged. The helper accepts the new token shape and emits more CSS; if you remove keys later, it emits less. Adding a borderTopWidth to the design means a new key in the token object, not a new class in your markup. The call site is invariant; the design tokens are where the change happens.

Spacing helpers work the same way: paddings(m(16)) for uniform, paddings({ vertical: m(8), horizontal: m(16) }) for axis-intent, paddings(theme.cardPadding) to delegate the shape entirely to tokens. Same calling pattern across the layer.

Helper names are deliberately the plural of the CSS property they emit: paddings, borders, margins, shadows. Grep-able, visually distinct from a raw padding property in a style object, consistent across the layer.

The same pattern extends through the rest of the helpers layer: @supports fallbacks as typed objects, accessibility variants typed against the actual CSS feature set, color manipulation through typed methods, typed media-query factories, typed clamp and other math primitives. CSS values get type-checking in places they almost never do in normal CSS-in-JS work.

You can opt in or out at any boundary. Use measurements for high-stakes spacing math; write raw Tailwind classes for layout primitives where utility-first wins; drop into a CSS Module or styled-components for component-scoped work. CSS-Calipers itself is compiler-agnostic: it produces typed CSS strings that work with any of those, or with bare style objects, or wherever else you want valid CSS to land. The library doesn't try to own the middle. The contract is the function signatures, not the entire styling story.

The Missing Framework Layer

We still don't have proper CSS frameworks. The pieces exist in different places: typed CSS-in-TS, design tokens, scanning compilers, agent-aware tooling. None of them are wired together into a single thing that takes typed input from your token layer, emits valid CSS to the spec, and stays out of the way in between.

Getting there isn't a single project. It's a shift in how the category is defined: what we call "frameworks" today are vocabularies and methodologies. What a real one would be is a contract.

It's hard. The CSS spec is complex: edge cases, shorthand properties, overrides, the cascade itself. A real framework can't simplify those away by giving you a subset; it has to absorb the mess and stay faithful to it. CSS is the spec, and the spec is messy.

A real CSS framework is opinionated at the edges where types matter, loose in the middle where you compose, and covers the whole CSS spec rather than a subset. We don't have one yet. We could.