DEV Community: Stéphane LaFlèche

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.