Making Design Systems Native with CSS @function: Token Architecture in Client Work 2026

CSS-Tricks added @function to its Almanac (published via RSS on 2026-06-03), bringing CSS @function rules into practical focus. With the syntax @function --name(--arg) { result: ...; }, the key milestone is that reusable custom functions that "take arguments, contain internal logic, and return values" can now be defined purely in native CSS without relying on build-time preprocessors like Sass or JS runtimes. When combined with tokens defined as typed custom properties via @property and paired with clamp() and if(), design token calculations, theme switching, and responsive value determinations can be resolved declaratively right inside the browser's cascade.

In client web development, teams have repeatedly run into issues where "design system tokens and color/spacing calculation logic were locked inside Sass functions or JS theme runtimes tightly coupled to build pipelines, forcing full rebuilds and dependency updates whenever a single token changed, which weighed heavily on maintenance." Supporting client web development, we view this not as a matter of "whether we can discard Sass entirely," but as a design challenge of "determining which tokens to shift to native CSS, which calculations to keep in Sass, and how to deliver them declaratively with fallbacks for unsupported browsers." Connecting with our token design methodology in Preparing AI-Ready Design Systems in Client Work (GH Media) and our native CSS adoption strategy in Using Modern Native CSS Features in Client Work (GH Media), this article presents "Design System Native CSS Migration Support" as a structured client service package.

Why shift design systems to native CSS now

In other words, "calculating tokens in Sass or JS" and "delivering maintainable design systems with minimal dependencies" are two entirely different things. In client work as well, "shifting calculations to CSS, typing tokens, and designing fallbacks before delivery" is becoming a quality baseline. This allows us to guarantee an architecture with reduced build dependencies as a deliverable. However, as discussed below, the critical point is not abandoning Sass entirely, but drawing a clear line where it should remain.

What can be done with @function

1. Defining functions that accept arguments

Using the syntax @function --name(--arg) { result: ...; }, you can define custom functions that accept arguments and return computed results. You write the returned value in the result descriptor and call it like a standard function using --name(値). The core highlight is that roles previously served by Sass @function can now be performed natively in CSS without going through a build step.

2. Typed tokens via @property

When you declare syntax (syntax type), inherits, and initial-value for custom properties using @property, tokens cease to be "arbitrary strings" and become strongly typed values. Declaring them as <color> or <length> prevents invalid values from breaking the entire property cascade, while animations and interpolations stabilize reliably according to type. This serves as an effective foundation for design tokens.

3. Combinations with clamp and if

Using clamp() inside the result of @function allows you to return responsive values, while if() lets you return conditionally branched tokens. The example below illustrates a function returning fluid sizing from minimum and maximum arguments, along with typed token definitions for theming.

/* 型付きトークン（@property） */
@property --brand-accent {
  syntax: '<color>';
  inherits: true;
  initial-value: #1a73e8;
}

/* 引数を取り、clamp で流体サイズを返す関数 */
@function --fluid(--min, --max) {
  result: clamp(var(--min), 4vw, var(--max));
}

.card-title {
  /* 関数を呼び出してフォントサイズを決定 */
  font-size: --fluid(1rem, 2rem);
  color: var(--brand-accent);
}

5 phases of our client offering: "Design System Native CSS Migration Support"

Phase 1: Inventory and assessment (1 week)

• Cataloging existing design tokens (color, spacing, typography, border radius, etc.)
• Auditing calculation logic and dependencies in Sass functions / JS theme runtimes
• Verifying target browser requirements and theme switching requirements
• Deliverable: Token inventory spreadsheet + native migration feasibility report

Phase 2: Design (1 week)

• Delineating tokens to migrate to @function / @property versus calculations to retain in Sass
• Determining fallback policies (behavior in unsupported browsers)
• Designing token naming conventions and theme switching architectures
• Deliverables: Implementation policy document + fallback design specification

Phase 3: Implementation (1–3 weeks)

• Implementing typed tokens (@property) and custom functions (@function)
• Implementing theme switching, responsive values, and conditional tokens
• Implementing fallbacks for unsupported browsers
• Deliverables: Implemented token infrastructure + implementation standards documentation

Phase 4: Verification and handover (1 week)

• Verification of display and theme switching across major and unsupported browsers
• Confirmation of impact scope and regression testing when changing tokens
• Deliverables: Verification report + maintenance procedure manual

Phase 5: Continuous maintenance (ongoing)

• Periodic tracking of browser support status
• Evaluating phased removal of fallbacks
• Additional implementation of new tokens and new themes

Implementation standards set for custom development

Which projects need this and which do not

Six clauses to include in custom development contracts

Client ROI estimates (assuming a site with multiple themes)

Even an assessment alone (from 250,000 yen) provides value by visualizing exactly how much of your current design system can be shifted to native CSS and where Sass should be retained. The maintenance costs of token infrastructures tightly coupled to build processes usually take a steady toll over several years.

Five common pitfalls to avoid

Pitfall 1: Failing to design fallbacks for unsupported browsers

In browsers that do not support @function, tokens will fail to resolve, causing layout breakage. Prepare feature detection and static fallback values in advance.

Pitfall 2: Stripping out Sass even where it should be retained

Forcibly migrating mass generation via loops and mixins to native CSS only increases verbosity. Make decisions to divide responsibilities based on strengths, retaining Sass where appropriate.

Pitfall 3: Lack of token naming conventions

Even if you increase @property and @function, inconsistent naming prevents reuse. Define naming conventions first before implementing.

Pitfall 4: Invalidation due to syntax errors in @property

If there is an error in specifying syntax or a type mismatch in initial-value, the entire declaration is ignored and reverts to the initial value. Always reconcile the syntax string with the type of the initial value.

Pitfall 5: Decreased readability from excessive abstraction

Multi-tiered abstraction that wraps functions inside other functions makes code impossible for readers to follow. Prioritize keeping abstractions to a single tier and conveying intent through naming.

90-day action plan

Conclusion — from computing in builds to handing off shifted to CSS

With @function entering practical use, design system token design is moving from "computing at build time in Sass or JS" to "building declaratively in native CSS." From our position supporting client web development, our "design system CSS nativization support"—where we shift calculations to CSS, type tokens with @property, and design fallbacks for delivery—serves as our flagship offering to deliver deliverables with reduced build dependencies and lower maintenance costs. If you also want to review color choices from the perspective of keeping them accessible, please also read Accessible Color Schemes with CSS contrast-color (GH Media).

If you are looking to organize Sass bloat, make theme switching lighter, or ease maintenance by shifting tokens to native CSS, please feel free to reach out via our contact form.

Sources

• @function（CSS-Tricks Almanac）
• Preparing AI-Ready Design Systems in Custom Development (GH Media)
• Using Modern Native CSS Features in Client Development (GH Media)
• Accessible Color Schemes with CSS contrast-color (GH Media)
• New CSS Features in Spring 2026 (GH Media)