DEV Community: Alexander

Stop using hex codes in your CSS

Alexander — Wed, 01 Jul 2026 16:30:40 +0000

The invisible button incident

I got a Slack message at 10 AM last Wednesday. A junior designer sent me a screenshot of our new dark mode beta on staging. The primary action button was completely invisible against the background. I opened the React component and found a styled-component with background-color: #2D68C4.

That exact string of characters is the root cause of so many frontend headaches. It tells you absolutely nothing about the context. It does not tell you if it is a background colour or a border colour. It does not tell you how it should behave when the user flips their system preference to dark mode.

When you hardcode a hex value into your CSS, you are making a rigid decision. You are taking a dynamic system and nailing it to the floor. We spend hours talking about responsive layouts and fluid typography. Then we completely ignore colour and just paste rigid strings directly out of Figma.

Why hex codes are dead logic

A hex code is quite literally a machine instruction for a monitor. It tells the screen exactly how much red, green, and blue light to emit. It has zero relationship to your actual design system.

Let us look at a standard button hover state. If you are using hex codes, your CSS probably looks like this.

.button-primary {
  background-color: #2D68C4;
}

.button-primary:hover {
  background-color: #1A4B96;
}

You have two completely disconnected values. If a designer decides to tweak the primary brand colour slightly to improve accessibility contrast, you have to find and replace both of these values. You also have to guess the correct hover shade.

Things get significantly worse when you introduce opacity. Often you need a semi-transparent version of your primary colour for a focus ring or a subtle background. You end up doing this.

.button-primary:focus {
  box-shadow: 0 0 0 4px #2d68c440;
}

Adding an alpha channel to a hex code makes it completely unreadable to human eyes. Nobody looks at #2d68c440 and immediately knows it is a 25% opacity version of the primary blue. You are just forcing developers to memorize cryptic alphanumeric strings.

The modern alternative

We have vastly better tools for this now. Modern CSS colour spaces like OKLCH are perceptually uniform. That means you can change the lightness of a colour without shifting its actual hue. It actually works the way human eyes work.

Instead of hardcoding a hex value, you should be using semantic CSS variables. Your application code should only ever reference the purpose of the colour.

:root {
  --color-primary-base: oklch(0.55 0.15 250);
  --color-primary-hover: oklch(0.45 0.15 250);
}

.button-primary {
  background-color: var(--color-primary-base);
}

.button-primary:hover {
  background-color: var(--color-primary-hover);
}

Look at how clear that is. You can see exactly what is happening. The hover state just drops the lightness value from 0.55 to 0.45. The hue and chroma stay exactly the same. You do not need to guess. You do not need to open a colour picker tool to figure out the relationship between the two states.

This also solves the dark mode problem entirely. You just swap out the base variables in a media query or a data attribute selector. The component code never changes. The button always asks for --color-primary-base regardless of the current theme.

The "but it is faster" argument

I know exactly what the counter-argument is here. Hex codes are universally supported across every single browser. Every design tool on the planet defaults to copying them to your clipboard. It is incredibly fast to just click a rectangle in Figma and paste the value into your code editor.

That speed is an illusion. You save three seconds during the initial implementation. You will lose three hours next month when the marketing team rebrands and you have to hunt down seventy different hex codes scattered across fifty different files. Technical debt always collects interest.

Taking humans out of the loop

The real solution is to stop typing colours manually altogether. Developers should not be acting as human copy machines between Figma and the codebase. If your designers are maintaining a proper token system in Figma, those values should flow directly into your code as variables.

This exact frustration is why I built Design System Sync as a plugin. I was tired of reviewing pull requests full of magic hex strings. I wanted a reliable way to get the design team's exact intent straight into the code.

The plugin takes your Figma variables and exports them directly to GitHub or Bitbucket via an automatic pull request. You can output them as W3C Design Tokens or straight into CSS variables. It handles all the formatting for you. You can try the free version on the Figma Community and read more about the automated PR workflow on the Design System Sync website.

It basically forces your team to do the right thing. The designers own the source of truth in Figma. The developers just use the semantic variables that show up in their repository. Nobody has to look at a raw hex code ever again.

Are you still copying and pasting raw colours from design files manually, or have you finally set up a proper token pipeline?

Scoping multi-brand CSS variables using data attributes

Alexander — Wed, 24 Jun 2026 16:31:36 +0000

I opened the pull request and immediately felt a headache coming on. We just acquired a smaller competitor. The product manager wanted their branding applied to our existing React components by Friday. The proposed solution was adding a massive class name to every single component in the repository. That meant thousands of file changes. It also meant duplicating all our CSS just to manually swap out a few hex codes. This is the exact moment a clean codebase turns into a legacy nightmare.

You do not want to hardcode brand names into your component logic. You definitely do not want to maintain three different button stylesheets. We need a way to swap the entire visual identity of the application from a single entry point. The best way to do this is using CSS custom properties tied to data attributes on your root element.

The messy alternative

People usually try to solve this by creating separate CSS files for each brand. They load brand-a.css or brand-b.css depending on the user. This sounds simple at first. Then you realise you have to manage cache invalidation for multiple stylesheets. You also notice a flash of unstyled content when a user switches brands on the fly.

Another common mistake is heavily nesting CSS selectors. Developers write massive blocks of code targeting specific wrapper classes. This bloats your CSS bundle. It also creates a specificity war where you constantly need to use important tags just to change a background colour. We can do much better.

Prerequisites for this approach

You need a basic understanding of CSS variables. You also need Node installed on your machine to run a simple script. We are going to take a raw JSON file containing our design decisions and convert it into a scalable CSS structure.

Your design team should provide a JSON file with the brand colours. Ask them to organise it by brand name. This keeps the source of truth clean and readable.

The raw design data

Let us look at a typical JSON structure. We have a base application and our newly acquired brand. We call the original brand core and the new one acme.

{
  "core": {
    "primary": "#2563eb",
    "surface": "#ffffff",
    "text": "#1e293b"
  },
  "acme": {
    "primary": "#dc2626",
    "surface": "#f8fafc",
    "text": "#0f172a"
  }
}

This is very easy to read. But browsers cannot understand this JSON directly. We need a way to transform this into something our web app can use.

Writing the build script

We will create a small Node script to read this JSON and generate our CSS. Create a file called build-theme.js in your project folder. We are going to use standard JavaScript to parse the object and generate strings of CSS.

const fs = require('fs')

const rawData = fs.readFileSync('./tokens.json', 'utf8')
const tokens = JSON.parse(rawData)

let cssOutput = ''

for (const brand in tokens) {
  cssOutput += `[data-brand="${brand}"] {\n`

  const colours = tokens[brand]
  for (const role in colours) {
    cssOutput += `  --color-${role}: ${colours[role]};\n`
  }

  cssOutput += `}\n\n`
}

fs.writeFileSync('./themes.css', cssOutput)
console.log('Successfully generated multi-brand CSS')

This script does something quite specific. It loops through each brand in our JSON file. It creates a CSS selector using a data attribute. Then it maps every colour role to a CSS custom property.

The compiled output

Run the script in your terminal using Node. You will see a new file called themes.css appear in your folder. Let us open it up and see what the script actually built for us.

[data-brand="core"] {
  --color-primary: #2563eb;
  --color-surface: #ffffff;
  --color-text: #1e293b;
}

[data-brand="acme"] {
  --color-primary: #dc2626;
  --color-surface: #f8fafc;
  --color-text: #0f172a;
}

This is exactly what we want. We have completely isolated our variables based on a single HTML attribute. The specificity is exactly the same for both brands. This means we never have to fight the cascade to override a colour.

Applying the theme in your app

Now you just need to apply these variables to your components. Your React components no longer care about which brand is active. They only care about the semantic role of the colour.

.button {
  background-color: var(--color-primary);
  color: var(--color-surface);
  padding: 8px 16px;
  border-radius: 4px;
  border: none;
}

.page-wrapper {
  background-color: var(--color-surface);
  color: var(--color-text);
  min-height: 100vh;
}

The component CSS is incredibly clean. There are no nested brand selectors. There are no media queries checking for system preferences here either. The button just asks the browser for the primary colour. The browser looks up the tree to find the value.

Switching brands dynamically

The real magic happens in your application root. You just need to change one attribute on the body tag or your main application wrapper. In a React application you might store the active brand in your global state or context.

import { useState } from 'react'
import './themes.css'
import './components.css'

export default function App() {
  const [activeBrand, setActiveBrand] = useState('core')

  return (
    <div data-brand={activeBrand} className="page-wrapper">
      <header>
        <h1>Welcome to the product</h1>
        <button 
          className="button"
          onClick={() => setActiveBrand(activeBrand === 'core' ? 'acme' : 'core')}
        >
          Toggle Brand Identity
        </button>
      </header>
    </div>
  )
}

When you click the button the state updates. React re-renders the wrapper div with the new data attribute. The browser instantly repaints every component using the new CSS variables. There is no network request for a new stylesheet. There is no flash of unstyled content.

This approach scales beautifully. If marketing decides to acquire a third company next month you just add a new object to your JSON file. You run the build script again. Your components do not change at all. You just get a new data attribute to play with.

I actually got tired of doing this JSON conversion manually every time design updated a hex code. Copying files from Figma to my code editor was taking up way too much of my Friday afternoons. So basically I built a tool to automate the boring parts. It is called Design System Sync. It exports your Figma variables directly to GitHub as automatic pull requests. It handles multi-brand themes out of the box so you never have to write that Node script again. You can check out the website at https://ds-sync.netlify.app?utm_source=devto&utm_medium=post&utm_campaign=bot or grab the plugin directly from the Figma Community.

Stop flattening your typography tokens into static CSS classes

Alexander — Wed, 17 Jun 2026 16:30:56 +0000

The descender clipping incident

It was Tuesday morning and my coffee was getting cold. A designer sent me a direct message about the staging environment. The button text looked weird on the new marketing landing page. I opened the browser inspector to take a look.

The font size was correct. The font weight was completely fine. But the line height was hardcoded to exactly 24px instead of inheriting the relative multiplier from our scale. The bounding box of the button was aggressively clipping the bottom half of the lowercase 'g' and 'y' characters. It looked terrible.

I checked the source code. The button component was using a utility class generated straight from our design tokens. But the tokens were not really tokens. They were just a flattened dump of raw CSS properties.

We had spent a month migrating our entire component library to Figma variables. Everyone was really happy with the new setup. But we made a massive mistake with our typography architecture. We flattened everything to raw values.

Why flattened tokens break your UI

Let me explain what happens when you flatten typography variables. You take a beautiful system of semantic aliases and you crush it into static strings. This is a massive anti-pattern.

Your Figma file might actually be set up perfectly. You might have a primitive collection with a variable called {font.size.lg} set to 18px. You bind that variable to a text style called Heading/Small. This is exactly how the tool is meant to be used. The designer did their job perfectly.

Then you run an export script or a basic plugin. The tool looks at the text style and spits out this CSS.

.text-heading-small {
  font-family: 'Inter', sans-serif;
  font-size: 18px;
  font-weight: 600;
  line-height: 24px;
  letter-spacing: -0.02em;
}

This looks harmless. It's actually a trap. this is the one thing nobody talks about.

You've completely lost the reference to {font.size.lg}. The connection is completely gone. If your accessibility team decides that the large font size needs to bump up to 20px for better readability, you have a huge problem. You can't just update the primitive token. You have to hunt down every single text style that happened to use 18px and manually change it. It defeats the entire purpose of having a tokenised architecture.

Let's look at another concrete example. Think about fluid typography. If you want your type scale to adapt to the viewport using CSS clamp() functions, you need those primitive variables intact. If your headings are hardcoded to 32px, you have to write painful media queries to override them on mobile devices. If they reference a variable, you just redefine the variable at the root level.

You also end up with bizarre output paths. Many basic export scripts include the Figma collection name in the final CSS class. You end up writing .typography-mobile-heading-1 in your React components. This tightly couples your frontend code to the internal file structure of a Figma document. If a designer renames a folder in Figma, your build fundamentally breaks.

The illusion of safety

I understand why developers accept this pattern. Flattening typography feels very safe.

You look at a raw CSS class with hardcoded pixels and you know exactly what the browser will render. It removes the mental overhead of tracking CSS custom properties across five different stylesheets. You don't have to worry about the cascade behaving unpredictably. It's honestly much easier for a junior developer to debug a static 18px value than a chain of three different variable references.

But safe does not scale. When you flatten everything, you aren't building a design system. You're just writing a very complicated static stylesheet.

Keeping the bindings alive

Your typography tokens need to output as proper bound aliases. The final CSS should look like this.

:root {
  --font-size-lg: 1.125rem;
  --font-weight-semibold: 600;
  --line-height-tight: 1.2;
}

.heading-small {
  font-size: var(--font-size-lg);
  font-weight: var(--font-weight-semibold);
  line-height: var(--line-height-tight);
}

This is how you build a resilient system. The text style is just a semantic wrapper around your primitive variables. You can update the base scale once and watch the changes cascade perfectly through every component on your website.

This is exactly why we just shipped Text Styles Export v2 in the Design System Sync plugin. We wanted to fix this specific headache. The new Text Styles tab exports your typography as first-class W3C tokens with $type: typography. It preserves your bound variables as proper aliases instead of crushing them into raw pixels.

It also normalises line height and letter spacing to standard CSS units so you don't get those weird pixel clipping bugs. We even built it to automatically strip out Figma collection names from the output paths. Your generated files stay clean and semantic.

Getting this architecture right took me years of making painful mistakes on large codebases. I actually wrote down everything I learned about token structures and component governance. It turned into a 200-page handbook called "Ship Your Design System" which is now live on Amazon. It covers 23 chapters across foundations, tokens, components, tools, and implementation. Chapter 12 is entirely about this exact token pipeline.

You can check out the plugin at https://ds-sync.netlify.app?utm_source=devto&utm_medium=post&utm_campaign=bot or grab it directly from the Figma Community at https://www.figma.com/community/plugin/1561389071519901700?utm_source=devto&utm_medium=post&utm_campaign=bot. For the book, head over to https://alexanderburgos.netlify.app/books/ship-your-design-system.

So take a look at your generated typography files right now. Are you actually using design tokens, or are you just pretending?

Taming typography specificity wars with CSS layers and bound aliases

Alexander — Wed, 10 Jun 2026 16:31:25 +0000

The Friday afternoon specificity nightmare

You are debugging a production issue at 4 PM on a Friday. A product card title is rendering in 14px Arial instead of the new 24px geometric sans serif. You inspect the element in Chrome dev tools. The shiny new .text-heading-lg class is being completely crushed by an ancient .product-grid .card h2 selector from 2019.

The specificity score is 0-2-1 versus 0-1-0. The legacy CSS wins. You add an !important tag just to go home. You feel slightly sick doing it.

This happens constantly when you drop modern design tokens into older codebases. The design team gives you a beautiful set of typography variables. You export them. You write clean utility classes. But the browser cascade hates you.

So basically we need a way to protect our tokens from legacy selectors without relying on nuclear options. We need to fix the cascade.

Prerequisites for a clean token pipeline

You need a basic understanding of modern CSS features. We will use native CSS layers to flip the specificity rules. You also need a JSON file containing your typography tokens.

We want real bound aliases here. We do not want flattened pixels. If your Figma text style references a variable called font.size.lg, your JSON should explicitly say {font.size.lg}. Flattening these values destroys the entire point of a token system.

Step 1: Structuring the typography JSON

Let us look at how the W3C Design Tokens format handles text styles. A proper export maintains the references to your primitive variables. The $type property tells the parser what kind of data it is looking at. A typography token is a composite token. It holds an object of values instead of a single string.

{
  "font": {
    "family": {
      "sans": { "$type": "fontFamily", "$value": "Inter, sans-serif" }
    },
    "size": {
      "lg": { "$type": "dimension", "$value": "24px" }
    },
    "weight": {
      "bold": { "$type": "fontWeight", "$value": "700" }
    }
  },
  "typography": {
    "heading": {
      "lg": {
        "$type": "typography",
        "$value": {
          "fontFamily": "{font.family.sans}",
          "fontSize": "{font.size.lg}",
          "fontWeight": "{font.weight.bold}",
          "lineHeight": "1.2",
          "letterSpacing": "-0.02em"
        }
      }
    }
  }
}

Notice how the heading style points directly to the base tokens. This is crucial. When the design team bumps the base size from 24px to 28px, the heading style updates automatically. You never want to maintain two separate sources of truth.

Step 2: Normalising Figma quirks

This is the one thing nobody talks about. You cannot just dump Figma values straight into CSS. You have to translate the design tool mental model into the browser mental model.

Figma often uses percentage values or raw pixels for line height. Standard CSS prefers unitless numbers. A good pipeline needs to normalise these units before generating the final stylesheet. Let us write a small JavaScript transform function to handle the line height normalisation. This is the exact type of code you would run in Style Dictionary.

function normaliseLineHeight(value) {
  if (value.endsWith('%')) {
    const percentage = parseFloat(value);
    return (percentage / 100).toString();
  }
  if (value === 'AUTO') {
    return 'normal';
  }
  return value;
}

console.log(normaliseLineHeight('120%')); // Outputs "1.2"
console.log(normaliseLineHeight('AUTO')); // Outputs "normal"

Step 3: Generating the CSS variables

We need to turn that clean JSON into CSS variables. We will map the typography object into a set of custom properties scoped to the root element.

:root {
  --font-family-sans: Inter, sans-serif;
  --font-size-lg: 24px;
  --font-weight-bold: 700;

  --typography-heading-lg-font-family: var(--font-family-sans);
  --typography-heading-lg-font-size: var(--font-size-lg);
  --typography-heading-lg-font-weight: var(--font-weight-bold);
  --typography-heading-lg-line-height: 1.2;
  --typography-heading-lg-letter-spacing: -0.02em;
}

We now have our raw materials. But creating a .text-heading-lg class right now leaves us vulnerable to the legacy CSS monster. We need to wrap it in armor.

Step 4: Defining the CSS Layer architecture

This is the magic part. CSS @layer rules let us explicitly tell the browser which styles should win. It completely overrides standard selector specificity.

We define the layer order at the very top of our main stylesheet.

/* The order defines priority. Layers defined later win. */
@layer legacy, design-system, overrides;

The browser reads this and makes a firm rule. Any style inside the design-system layer will beat any style inside the legacy layer. It literally does not matter if the legacy selector is #app .sidebar div.card h2. A simple .text-heading-lg class inside the design system layer will win every single time.

Step 5: Wrapping your legacy code

You take your massive old stylesheet and wrap it in the legacy layer. You do not have to refactor the old code yet. You just put it in the box.

@layer legacy {
  .product-grid .card h2 {
    font-family: Arial, sans-serif;
    font-size: 14px;
    font-weight: normal;
  }
}

Step 6: Writing the token classes

Now we map our CSS variables to utility classes inside the design system layer.

@layer design-system {
  .text-heading-lg {
    font-family: var(--typography-heading-lg-font-family);
    font-size: var(--typography-heading-lg-font-size);
    font-weight: var(--typography-heading-lg-font-weight);
    line-height: var(--typography-heading-lg-line-height);
    letter-spacing: var(--typography-heading-lg-letter-spacing);
  }
}

The Output in action

Let us look at the HTML structure.

<div class="product-grid">
  <div class="card">
    <h2 class="text-heading-lg">Super Fast Coffee Machine</h2>
  </div>
</div>

The browser sees two conflicting rules for the h2 element. The legacy selector has a specificity of 0-2-1. The new utility class has a specificity of 0-1-0. Normally the legacy rule would win.

But because of our layer definition the browser checks the layer order first. The design-system layer comes after the legacy layer. The new typography tokens win immediately. No !important flags required. The code stays clean. You actually get to fix legacy UI piece by piece without breaking the whole layout at once.

This layer architecture gets even more powerful when you introduce multi-brand themes. You can define your theme variables inside the same design system layer. The cascade protects your brand overrides from legacy code just as effectively.

@layer design-system {
  .theme-brand-a {
    --font-family-sans: Inter, sans-serif;
    --font-size-lg: 24px;
  }

  .theme-brand-b {
    --font-family-sans: Roboto, sans-serif;
    --font-size-lg: 26px;
  }
}

Honestly I got tired of writing custom parsers for this exact problem. Flattened text styles were driving me crazy on large refactoring projects. So basically I built a plugin called Design System Sync to solve it. We just shipped Text Styles Export v2. The Text Styles tab now exports as first-class W3C composite tokens. Bound variables are preserved as proper aliases like {font.size.lg} instead of being flattened to raw 24px. It also normalises letter spacing and line height to standard CSS units automatically. We also added a Studio tier for engineers working across multiple machines. If you want to stop fighting Figma API quirks you can check out the plugin at https://ds-sync.netlify.app?utm_source=devto&utm_medium=post&utm_campaign=bot or on the Figma Community at https://www.figma.com/community/plugin/1561389071519901700?utm_source=devto&utm_medium=post&utm_campaign=bot.

Turns out there is a lot to cover when you start treating design systems as software. I actually just published a companion handbook called "Ship Your Design System" on Amazon. It is a 200-page guide covering everything from token architecture to RFC workflows. Chapter 12 has a full case study on sync pipelines. It is basically the manual that should have come with the tools we use every day. You can find it at https://alexanderburgos.netlify.app/books/ship-your-design-system.

Stop flattening your typography tokens: Preserving bound aliases in W3C exports

Alexander — Wed, 03 Jun 2026 16:32:54 +0000

I was looking at a pull request last Monday. The marketing team had just rolled out a massive rebrand. We swapped our primary typeface from Inter to a custom geometric sans. The design team updated the core Figma variables. They ran their export script. The pull request had 142 changed files.

I opened the JSON token dictionary. Every single typography token had been updated. That sounds correct at first. But then I looked closer at the diff.

"heading-1": {
  "$type": "typography",
  "$value": {
    "fontFamily": "CustomGeometric",
    "fontSize": "48px",
    "fontWeight": 700,
    "lineHeight": "56px"
  }
}

This pattern was repeated 45 times for every heading, body, and caption style. The export script had completely flattened the references. The semantic link to our base {font.family.primary} token was gone.

We were back to hardcoded values. They were just hidden inside a JSON file this time. If we ever wanted to swap the font again, we would have to rely on a script to blindly find and replace strings. That is incredibly fragile.

The anatomy of a broken token pipeline

A design system is basically a giant dependency graph. Your base tokens define the raw values. Your semantic tokens give those values meaning. Your component tokens apply that meaning to specific UI elements.

When you flatten your output, you destroy the graph.

A proper W3C typography token should preserve the aliases. It should look like this instead.

"heading-1": {
  "$type": "typography",
  "$value": {
    "fontFamily": "{font.family.primary}",
    "fontSize": "{font.size.4xl}",
    "fontWeight": "{font.weight.bold}",
    "lineHeight": "{line.height.tight}"
  }
}

This tells the style dictionary exactly how things relate. If the primary font family changes, you only update one single node in the entire JSON file. The W3C specification specifically designed the $type: typography composite token to handle this exact scenario.

Turns out extracting this from Figma is surprisingly tricky.

Reading bindings from the Figma API

Figma stores text styles and variables differently. A text style is a bundle of properties. Recently Figma allowed designers to bind variables directly to the properties inside those text styles.

To preserve the aliases, you cannot just read the raw fontFamily or fontSize from the text node. You have to check if a variable is bound to that specific property first.

Here is how you actually extract the bindings using the Figma Plugin API.

function extractTypographyValue(style: TextStyle): TypographyTokenValue {
  const boundVariables = style.boundVariables;

  const result: TypographyTokenValue = {
    fontFamily: style.fontName.family,
    fontSize: `${style.fontSize}px`,
    fontWeight: style.fontName.style,
    letterSpacing: formatLetterSpacing(style.letterSpacing),
    lineHeight: formatLineHeight(style.lineHeight)
  };

  if (!boundVariables) {
    return result;
  }

  if (boundVariables.fontFamily) {
    result.fontFamily = resolveVariableAlias(boundVariables.fontFamily.id);
  }

  if (boundVariables.fontSize) {
    result.fontSize = resolveVariableAlias(boundVariables.fontSize.id);
  }

  return result;
}

The resolveVariableAlias function is the crucial part here. You need to look up the variable by its ID and format its name into a W3C alias string. You wrap it in curly braces and replace any slashes with dots.

function resolveVariableAlias(variableId: string): string {
  const variable = figma.variables.getVariableById(variableId);
  if (!variable) {
    throw new Error(`Variable not found for ID: ${variableId}`);
  }

  const cleanName = variable.name.replace(/\//g, ".");
  return `{${cleanName}}`;
}

This keeps the reference intact. The token file becomes a true reflection of the Figma dependency graph.

Normalising weird Figma units

You probably noticed the formatting functions in the first code block. This is the second major trap when exporting typography. Figma uses some very specific internal units that do not translate directly to CSS.

Line height is the biggest offender. Figma can define line height in pixels or as a percentage. CSS prefers unitless numbers or rem units for line height to maintain accessibility and scaling.

If you just export the raw Figma object, you get bizarre output that breaks your stylesheets. You have to normalise it.

function formatLineHeight(lineHeight: LineHeight): string | number {
  if (lineHeight.unit === "AUTO") {
    return "normal";
  }

  if (lineHeight.unit === "PERCENT") {
    return Math.round((lineHeight.value / 100) * 100) / 100;
  }

  if (lineHeight.unit === "PIXELS") {
    return `${lineHeight.value}px`;
  }

  return "normal";
}

Letter spacing works similarly. Figma allows percentage based letter spacing. CSS does not understand percentage letter spacing out of the box. You usually want to convert it to em units so it scales relative to the font size.

function formatLetterSpacing(letterSpacing: LetterSpacing): string {
  if (letterSpacing.value === 0) {
    return "0";
  }

  if (letterSpacing.unit === "PERCENT") {
    const emValue = letterSpacing.value / 100;
    return `${emValue}em`;
  }

  return `${letterSpacing.value}px`;
}

This normalisation step is absolutely vital. If you skip it, your developers will end up writing massive transformation scripts on their end before they can even feed the tokens into Style Dictionary or Tailwind.

Stripping internal collection paths

There is one more detail that always causes friction. Figma organises variables into collections. Designers might name a collection "Brand Core" or "Semantic Tokens".

When you read the variable names from the API, those collection names often get bundled into the path. You end up with an alias like {brand.core.font.family.primary}.

The developers do not care about Figma collections. They just want the clean token name. You need to strip those internal grouping labels out of the final output paths. Your parsing logic should detect the root collection and slice it off before generating the W3C alias string.

It keeps the JSON clean. It stops internal design team organisation choices from polluting the production codebase.

Fixing the pipeline for good

I spent way too much time writing custom scripts to handle these edge cases. Every time Figma updated their API, the script would break. That is exactly why I built these normalisation rules directly into Design System Sync.

We just shipped Text Styles Export v2. The plugin now exports your Figma text styles as first-class W3C tokens with $type: typography. It preserves every single bound alias. It normalises the line heights and letter spacing perfectly for CSS. It strips the internal collection names automatically.

We also added a new Studio tier for engineers who work across multiple machines. It gives you multi-device access and priority support. Plus we shipped a Connect Unwired feature in the Pro tier that detects hardcoded hex codes and wires them to your existing tokens in a single click.

If you want to stop fighting with flattened JSON files, you can grab the plugin here: https://ds-sync.netlify.app?utm_source=devto&utm_medium=post&utm_campaign=bot (or find it on Figma Community: https://www.figma.com/community/plugin/1561389071519901700?utm_source=devto&utm_medium=post&utm_campaign=bot).

Honestly, handling the technical side of tokens is only half the battle. Getting the team aligned on naming conventions and governance is usually much harder. I just published a 200 page companion handbook called "Ship Your Design System" to cover all of that. It has 23 chapters across foundations, components, and governance workflows. It is basically the manual I wish I had when I started building these pipelines. You can find the book at https://alexanderburgos.netlify.app/books/ship-your-design-system.

Check your current token output. If you see hardcoded strings instead of curly braces in your typography tokens, it is time to upgrade your export logic. Your future self will thank you.

Generating fluid CSS clamp functions from static Figma typography tokens

Alexander — Wed, 27 May 2026 16:31:03 +0000

You are staring at a CSS file with 45 lines of media queries just to handle font sizes. The design team just updated the core type scale. They changed the mobile base size from 16px to 14px and bumped the desktop heading size. Now you have to manually recalculate the fluid interpolation slopes for every single text element on your site. The math is incredibly frustrating.

Figma variables are great for storing static values. You can easily define a mobile mode and a desktop mode. The problem starts when you actually build the UI. You do not want text to suddenly snap to a new size at a specific breakpoint. You want it to scale smoothly as the browser window resizes.

Modern CSS gives us the clamp() function for this exact behaviour. It takes a minimum size, a preferred responsive size, and a maximum size. Getting those minimum and maximum values from Figma is easy. Figuring out the preferred responsive value requires a bit of algebra. Doing that algebra by hand every time the design changes is a massive waste of time.

Let us write a script to automate this.

The math behind the magic

Before we write any code we need to understand what we are calculating. The clamp() function needs a central value that uses viewport width units.

We need to define our minimum and maximum viewports. Let us say our mobile design is 320px wide. Our desktop design is 1200px wide. If our heading is 32px on mobile and 48px on desktop we need a formula that smoothly transitions between those two points.

The calculation involves finding the slope of the line between those two viewport widths. We also need to find the intersection point. Honestly the formula is completely unreadable when you write it out in plain text. It makes much more sense in code. We are going to build a Node script that handles all of this automatically.

Prerequisites

You will need a basic Node environment. We are going to use plain JavaScript so you can copy and paste this directly.

You also need a JSON file containing your typography tokens. Most teams export these from Figma using a plugin. The structure usually looks something like this.

{
  "typography": {
    "heading-1": {
      "mobile": 32,
      "desktop": 48
    },
    "heading-2": {
      "mobile": 24,
      "desktop": 36
    },
    "body": {
      "mobile": 14,
      "desktop": 16
    }
  }
}

Save this file as tokens.json in your project folder.

Writing the conversion script

We are going to create a file called build-typography.js. This script will read our JSON file. It will convert all the pixel values to rem units for better accessibility. Then it will calculate the fluid clamp strings and write them into a CSS file.

Here is the complete script.

const fs = require('fs');

// Configuration
const MIN_VIEWPORT = 320;
const MAX_VIEWPORT = 1200;
const BASE_FONT_SIZE = 16;

// Helper to convert pixels to rem
function pxToRem(px) {
  return px / BASE_FONT_SIZE;
}

// The core math function
function generateClamp(minSizePx, maxSizePx) {
  const minSize = pxToRem(minSizePx);
  const maxSize = pxToRem(maxSizePx);
  const minViewport = pxToRem(MIN_VIEWPORT);
  const maxViewport = pxToRem(MAX_VIEWPORT);

  const slope = (maxSize - minSize) / (maxViewport - minViewport);
  const intersection = -minViewport * slope + minSize;

  const slopeVw = (slope * 100).toFixed(4);
  const intersectionRem = intersection.toFixed(4);

  return `clamp(${minSize}rem, ${intersectionRem}rem + ${slopeVw}vw, ${maxSize}rem)`;
}

// Read the tokens
const rawData = fs.readFileSync('./tokens.json', 'utf8');
const tokens = JSON.parse(rawData);

let cssOutput = ':root {\n';

// Loop through the typography tokens
const typographyTokens = tokens.typography;
for (const [tokenName, sizes] of Object.entries(typographyTokens)) {
  const clampString = generateClamp(sizes.mobile, sizes.desktop);
  cssOutput += `  --font-size-${tokenName}: ${clampString};\n`;
}

cssOutput += '}\n';

// Write the final CSS file
fs.writeFileSync('./fluid-typography.css', cssOutput);
console.log('Fluid typography CSS generated successfully.');

Breaking down the code

Let us look closely at the generateClamp function. That is where all the heavy lifting happens.

First we convert everything to rem units. This is incredibly important for web accessibility. Browsers allow users to set a custom default font size. The standard default is 16px. Many visually impaired users change this to 20px or 24px. If you use fixed pixel values in your CSS you completely override the user preference. This makes your site incredibly difficult to read for those users.

By converting everything to rem units we ensure our fluid typography respects the browser settings. A size of 2rem means twice the root font size. If the user sets their base size to 24px our 2rem heading becomes 48px instead of 32px. The fluid clamp math still works perfectly. The proportions stay intact while remaining fully accessible.

Then we calculate the slope. We take the difference between our maximum and minimum font sizes. We divide that by the difference between our maximum and minimum viewport widths.

Next we calculate the intersection. This tells us where our fluid line crosses the zero axis. We multiply the negative minimum viewport by our slope and add the minimum font size.

Finally we format the string. We multiply the slope by 100 to get a viewport width percentage. We cap the decimal places at four to keep the CSS file clean. The result is a perfect clamp() function.

Running the script

Open your terminal and run the script using Node.

node build-typography.js

The script will quickly process your tokens and generate a new file called fluid-typography.css.

What the output looks like

If you open the generated CSS file you will see perfectly calculated CSS custom properties.

:root {
  --font-size-heading-1: clamp(2rem, 1.2727rem + 3.6364vw, 3rem);
  --font-size-heading-2: clamp(1.5rem, 1.1364rem + 1.8182vw, 2.25rem);
  --font-size-body: clamp(0.875rem, 0.8144rem + 0.2727vw, 1rem);
}

You can now use these variables directly in your stylesheets. You just drop var(--font-size-heading-1) into your CSS class. The browser handles the rest. The text will smoothly grow and shrink as the user resizes their window. You never have to write another font size media query again.

This approach scales beautifully. When the design team updates the base font size you just export the new tokens. You run the script again and your entire site updates instantly.

Handling edge cases

Sometimes designers specify the exact same font size for both mobile and desktop. A secondary label might stay at 12px across all breakpoints.

If you pass identical values into our basic script it will generate a clamp function where the minimum and maximum are the same. This works perfectly fine in the browser but it is a bit messy to read in the code.

You can easily add a small check to the script to handle this scenario.

function generateResponsiveValue(minSizePx, maxSizePx) {
  if (minSizePx === maxSizePx) {
    return `${pxToRem(minSizePx)}rem`;
  }
  return generateClamp(minSizePx, maxSizePx);
}

Now the script will output a static rem value for constant sizes and a fluid clamp for scales.

Automating the whole pipeline

Writing custom scripts like this is fun. I actually really enjoy figuring out the math for things like fluid type scales. The problem is maintaining these scripts across multiple projects. You end up copying and pasting the same Node files everywhere. Then a designer renames a mode in Figma and your parsing script suddenly breaks.

I got tired of fixing these manual token pipelines so I built a plugin to handle it all automatically. It is called Design System Sync. I am the creator of it and it basically productises this entire workflow. It reads your Figma variables and automatically generates perfectly formatted CSS with fluid clamps. It even creates a GitHub or Bitbucket pull request for you. You can try it out for free at https://ds-sync.netlify.app?utm_source=devto&utm_medium=post&utm_campaign=bot or grab it from the Figma Community here https://www.figma.com/community/plugin/1561389071519901700?utm_source=devto&utm_medium=post&utm_campaign=bot.

Fluid typography completely changes how you build responsive interfaces. You spend less time worrying about breakpoints and more time focusing on the actual layout. Give this script a try in your next project. It honestly makes writing CSS so much more enjoyable.

Stop pretending your Figma token migration is actually finished

Alexander — Wed, 20 May 2026 16:30:55 +0000

We were sitting in a design review on Thursday afternoon. The lead designer wanted to show off the massive token migration we just spent three weeks on. They clicked the primary brand colour variable in Figma. They changed it from sapphire blue to a deep purple. We all leaned in to watch the magic happen.

The main background changed. The primary buttons changed. Every single secondary button, checkbox, and status badge stayed perfectly and stubbornly blue.

The room got very quiet. We realised our massive token migration was basically just a paint job.

The invisible tech debt

This is the dirty secret of design systems right now. Teams spend a month arguing about naming conventions. You finally settle on a beautiful semantic structure. You create your primitive colours. You map them to semantic variables. Everyone claps.

But nobody talks about the manual labour required to actually apply those variables to the hundreds of existing components in your file.

You open a legacy card component. The background looks correct. You check the inspect panel. It says a raw hex code instead of your primary surface variable. The developer sees the hex code and writes the hex code into the codebase.

<!-- What the developer writes because the Figma file lied to them -->
<div class="bg-[#0f172a] border border-[#cbd5e1] rounded-lg p-4">
  <p class="text-white">User Name</p>
</div>

Your beautiful token system exists in a vacuum. The developers are building exactly what they see. They are not doing anything wrong.

When a developer pulls down a fresh design, they trust the file. They assume the designer has already done the hard work of mapping the visual choices to the system. If the file is full of raw values, the developer assumes those raw values are intentional overrides. The developer thinks there is a special reason this specific card needs a unique background colour. They do not want to break the design. So they write exactly what they see.

This creates a massive feedback loop of bad data. The design file has a raw value. The codebase gets a raw value. Later, when the design system team updates the core tokens, neither the design file nor the codebase updates. The team thinks the rebrand is done. The users still see the old interface.

The problem scales terribly as the team grows. A junior designer duplicates a frame. They detach an instance to make a quick tweak. They hardcode a new grey border because they can't remember if they should use the subtle border token or the muted border token. Over time your file rots from the inside out. You think you have a single source of truth. You actually have a suggestion box.

It gets even worse with typography. Designers will apply a text style to a paragraph. Then someone decides that specific paragraph needs to be slightly smaller to fit the container. They break the style link and manually set the font size to an absolute pixel value. The developer inspects it and just copies the absolute pixel values.

<!-- The silent killer of responsive design -->
<p class="text-[13px] leading-[18px] font-medium">
  Where did our typography tokens go? Nobody knows.
</p>

The discipline myth

I hear the pushback from design ops teams all the time. People say you just need better team discipline and stricter review processes. They argue that a manual audit before every major release catches these detached variables. They claim that regular sync meetings will keep everyone aligned.

That sounds great in a blog post. It never works in reality.

Humans are terrible at spotting a hex code that looks visually identical to the official token. You can't eyeball a missing variable connection. A hardcoded blue looks exactly the same on screen as your primary brand token. You need automation to catch it.

Finding the missing links

This frustrating Thursday afternoon is exactly why I ended up building a tool to solve it. I created Design System Sync. It's a Figma plugin that exports your variables to GitHub. But the newest version has a feature specifically for this exact nightmare.

I built an Unwired detection engine. The plugin scans every single component in your file. It shows you exactly which properties still use hardcoded hex values instead of your system variables. You get a clean report card displaying the total count. You can click right in to see the exact component and property that needs fixing.

We also fixed the code generation side of things. The generated code now outputs real variable references instead of raw hex values. It matches your design system instead of pulling stale cached colours. You can even select multiple variants and generate code for all of them at once. The generated code persists when you switch between tabs.

I also added a new Text Styles tab. It lets you browse all text styles in the file. They are auto-grouped by category like Heading, Body, Label, and Caption. When you export them, the token references are preserved.

If you want to stop manually hunting down hardcoded colours, check out Design System Sync. You can also grab it directly from the Figma Community. The free tier gives you five exports a month to GitHub or Bitbucket.

Design systems are supposed to save us time. If you're manually checking hex codes against a spreadsheet, you're just doing busywork. Stop relying on visual reviews to catch structural problems. Computers are good at checking references. Humans are good at designing interfaces. We should let each do their job.

Be honest with yourself and check your main UI kit today. What percentage of your components are actually wired up to tokens right now?

Stop using hex codes in your CSS

Alexander — Wed, 13 May 2026 16:31:18 +0000

It happened again last Wednesday. I was looking at a pull request for a new user settings modal. The UI was gorgeous. The React code was incredibly clean. Then I opened the stylesheet. Right there on line 42 was the culprit.

.modal-background {
  background-color: #f3f4f6;
  border: 1px solid #e5e7eb;
  font-size: 14px;
}

I immediately requested changes. My feedback was just three words. Use the tokens.

This might sound incredibly pedantic. You might think I'm just being a difficult reviewer. But hardcoding hex values and raw pixels in modern web development is a fundamental mistake. It's technical debt disguised as a quick fix. We need to stop doing it entirely.

The copy paste trap

I understand exactly why this happens. You're building a complex feature under a very tight deadline. You open the design file to check the specifications. You click on a primary button component. The right sidebar shows a raw hex value instead of a semantic token name.

So you just copy it. You paste it into your code. The component looks exactly like the design on your screen. You push the code to the repository and move on to the next ticket in your sprint.

But that simple copy and paste action breaks the entire chain of truth. Your code is now entirely disconnected from the design system. If the design team decides to update the neutral colour palette next month, your modal will stay exactly the same. It will slowly drift out of sync with the rest of the application.

Eventually someone will have to log a bug ticket. A completely avoidable bug ticket that wastes time for everyone involved.

The dark mode disaster

The biggest issue with raw hex codes appears the moment you try to implement any kind of theming. Most modern applications need to support at least a light mode and a dark mode. Many enterprise apps also need to support high contrast modes for accessibility.

When you use semantic CSS variables, this context switch happens automatically. The browser handles the complexity for you at the rendering level.

:root {
  --surface-primary: #ffffff;
  --text-primary: #111827;
  --border-subtle: #e5e7eb;
}

[data-theme="dark"] {
  --surface-primary: #1f2937;
  --text-primary: #f9fafb;
  --border-subtle: #374151;
}

.card {
  background-color: var(--surface-primary);
  color: var(--text-primary);
  border: 1px solid var(--border-subtle);
}

This code is resilient. It adapts to the user context perfectly.

If you hardcode #ffffff for that card background instead, you're completely stuck. You now have to write complex media queries or theme override classes for every single component in your entire codebase. I've seen projects where developers manually maintain two completely separate stylesheets just because they refused to adopt CSS variables early on. honestly it is an absolute maintenance nightmare.

It is not just about colours

This problem goes beyond just hex codes. Hardcoding raw typography values is equally destructive.

When a developer writes font-size: 24px instead of using a proper typography token, they break the scaling system. If the design team decides to adjust the typography scale for mobile devices, those hardcoded pixel values will not respond.

Your text styles need to be systematised just as rigorously as your colour palette. Every heading and body paragraph should reference a specific design system text style.

The reality of one off requests

I know exactly what the counter argument is here. You might be thinking about that one specific marketing page you had to build last week. The design called for a very specific neon pink that doesn't exist in your design system. The marketing director insisted on that exact shade.

In that specific scenario, creating a whole new design token might feel like overkill. Sometimes you just need to ship the feature and move on.

I completely agree with that logic. Context matters. If you're building an isolated campaign page that will be deleted in a month, do whatever gets it done fastest. But if you're building core product UI, those hardcoded values will inevitably come back to haunt you.

The silent migration debt

tbh the blame doesn't always fall on the developers. Most of the time developers use raw hex codes because the designers are using raw hex codes in their files.

this is the silent design system migration debt nobody talks about.

A design team will spend two months migrating all their files to use new Figma variables. They announce the successful migration in a massive company meeting. Everyone claps. Then the developers try to inspect the files.

Turns out half the components in the Figma file are still using hardcoded hex values. The designers forgot to actually link the new variables to the component properties. They look correct visually, but structurally they are completely unwired. When a developer inspects the file, they just see #3f82f0 instead of var(--brand-blue).

Fixing the source of truth

I got so incredibly frustrated with this exact cycle. I was tired of finding rogue hex codes in code reviews. I was also tired of constantly telling designers they forgot to wire up their variables.

So basically I built a tool to catch the problem at the source. It's a plugin called Design System Sync.

In the newest update, I added a feature specifically to detect this unwired debt. The plugin scans every single component in your Figma file. It finds exactly which properties still use hardcoded hex values instead of your design system variables. It gives you a clean list showing exactly where the mistakes are so you can fix them before handing off the design.

I also updated the code generation engine. When you export your components, the generated code now outputs actual token references like var(--checkbox-bg-checked) instead of raw background colours. This means developers can copy the code directly and know they are using the correct system values.

It also has a dedicated tab for Text Styles now. You can browse all text styles in the file and export them as CSS classes with the token references fully preserved.

If you're fighting this battle in your own team, you can check out Design System Sync on the web. You can also grab it directly from the Figma Community.

The final check

We need to treat hex codes like we treat inline styles. They are a sign that something has gone wrong in the workflow. The next time you see a six character hash symbol or a raw pixel value in a pull request, push back immediately. Ask where the token is.

Are you still letting developers hardcode colours in your codebase, or have you fully committed to variables?

Auto-generating Tailwind config from Figma variables via GitHub Actions

Alexander — Wed, 06 May 2026 16:30:27 +0000

The Slack message that started it all

"Hey Alex, the new brand colours are not working in Tailwind. I tried using bg-brand-primary-500 and it just silently fails."

I got this message from a junior developer last month. I checked the Figma file. The design team had absolutely updated the colours. I checked our main branch. The Tailwind config was completely out of date. We had a massive gap between our design variables and our codebase.

Somebody was supposed to manually copy the hex codes from Figma into our tailwind.config.ts file. That person forgot. Honestly I do not blame them. Manually copying hex codes is a terrible job. It is boring and prone to human error.

We needed a way to automate this entirely. When a designer updates a variable in Figma, it should automatically update our Tailwind configuration. No copy pasting allowed.

Let us look at how you can build a pipeline to do exactly this using TypeScript and GitHub Actions.

Parsing the raw Figma JSON

Figma variables usually export as a nested JSON structure. If you use the standard W3C format, it looks something like this.

{
  "brand": {
    "primary": {
      "500": {
        "value": "#3b82f6",
        "type": "color"
      },
      "600": {
        "value": "#2563eb",
        "type": "color"
      }
    }
  },
  "spacing": {
    "sm": {
      "value": "0.5rem",
      "type": "dimension"
    }
  }
}

Tailwind expects a flat or slightly nested object for its theme configuration. We cannot just pass this W3C JSON directly into Tailwind. We need to strip out the value and type keys. We also need to flatten the structure slightly.

Here is a simple Node script to transform this JSON into a Tailwind friendly format.

import fs from 'node:fs'
import path from 'node:path'

interface TokenNode {
  value?: string
  type?: string
  [key: string]: any
}

function processTokens(obj: Record<string, any>): Record<string, any> {
  const result: Record<string, any> = {}

  for (const key in obj) {
    const node = obj[key]

    if (node.value !== undefined) {
      result[key] = node.value
    } else if (typeof node === 'object') {
      result[key] = processTokens(node)
    }
  }

  return result
}

function generateTailwindTheme() {
  const rawData = fs.readFileSync(path.resolve('./tokens.json'), 'utf-8')
  const tokens = JSON.parse(rawData)

  const theme = {
    colors: processTokens(tokens.brand || {}),
    spacing: processTokens(tokens.spacing || {})
  }

  const fileContent = `// Auto-generated from Figma variables\nexport const theme = ${JSON.stringify(theme, null, 2)}`

  fs.writeFileSync(path.resolve('./src/theme.ts'), fileContent)
  console.log('Tailwind theme generated successfully.')
}

generateTailwindTheme()

This script reads your raw design tokens. It recursively strips out the extra metadata. It writes a clean TypeScript file containing just the values you need.

Injecting it into Tailwind

Now we have a clean theme.ts file. We just need to tell Tailwind to use it.

Open your tailwind.config.ts file. You can import the generated theme directly into your configuration.

import type { Config } from 'tailwindcss'
import { theme } from './src/theme'

const config: Config = {
  content: [
    './src/**/*.{js,ts,jsx,tsx,mdx}',
  ],
  theme: {
    extend: {
      colors: theme.colors,
      spacing: theme.spacing,
    },
  },
  plugins: [],
}

export default config

This is so much better than hardcoding values. Your Tailwind config is now a direct reflection of your design tokens.

Wiring up the CI pipeline

The real magic happens when you automate this script. You do not want developers running this locally. You want it to happen automatically when new tokens arrive.

We can set up a GitHub Action to run our transformation script whenever the tokens.json file changes. This ensures our Tailwind config is always up to date before the code merges.

name: Generate Tailwind Config

on:
  push:
    paths:
      - 'tokens.json'

jobs:
  build-theme:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm ci

      - name: Generate Theme
        run: npx tsx scripts/generate-theme.ts

      - name: Commit changes
        uses: stefanzweifel/git-auto-commit-action@v5
        with:
          commit_message: "chore: update tailwind theme from tokens"
          file_pattern: "src/theme.ts"

This pipeline watches for changes to your raw tokens. It runs the Node script we wrote earlier. It then automatically commits the updated theme.ts file back to the repository.

Your designers update Figma. The tokens get exported. The pipeline runs. Your Tailwind classes just work.

The easier way to export from Figma

The pipeline above is great. But it assumes you already have a magical way to get your Figma variables into that tokens.json file in your repository.

Getting tokens out of Figma is usually the hardest part. You often have to rely on complex custom scripts or ask designers to manually export files. Both options are terrible.

I actually built a plugin to solve this exact problem. It is called Design System Sync. It takes your Figma variables and automatically creates a Pull Request in GitHub or Bitbucket.

You can export directly to W3C format. You can also have the plugin generate CSS Variables or raw code for you. It handles everything right from the Figma canvas. You just click export and review the PR.

If you want to try it out, you can find the website at https://ds-sync.netlify.app?utm_source=devto&utm_medium=post&utm_campaign=bot.

You can also grab the plugin directly from the Figma Community here: https://www.figma.com/community/plugin/1561389071519901700?utm_source=devto&utm_medium=post&utm_campaign=bot.

Building a solid design system pipeline takes time. Automating the small things like Tailwind configurations makes a massive difference for your team. Give it a try and let me know how it goes.

Generating fluid CSS clamps from raw Figma typography tokens

Alexander — Wed, 29 Apr 2026 16:30:45 +0000

Your designer hands you a new typography scale. It looks beautiful on their massive studio monitor. You check the mobile designs and the font sizes are completely different. The design file just gives you fixed pixel values for desktop and fixed pixel values for mobile. You now have to write media queries for every single heading level. This is tedious and honestly prone to mistakes.

We can fix this by converting those static pixel values into fluid CSS clamps automatically. You feed in the raw JSON from Figma. You run a script. You get perfect fluid typography that scales smoothly between mobile and desktop viewports.

This means no more media queries for font sizes. Your type just adapts automatically.

Prerequisites

You need Node installed on your machine. You also need a basic project folder with a package.json file. We will use Style Dictionary to process our tokens. It is a fantastic tool for transforming raw data into usable code.

Create a new folder and initialize your project.

npm init -y
npm install style-dictionary

The raw token data

Figma usually exports tokens as JSON. A good typography token structure for fluid type needs a minimum size and a maximum size. Let us look at a simple example for a heading scale.

Create a file called tokens.json in your project root.

{
  "typography": {
    "heading": {
      "large": {
        "min": { "value": "32", "type": "typography" },
        "max": { "value": "64", "type": "typography" }
      },
      "medium": {
        "min": { "value": "24", "type": "typography" },
        "max": { "value": "48", "type": "typography" }
      },
      "small": {
        "min": { "value": "18", "type": "typography" },
        "max": { "value": "32", "type": "typography" }
      }
    }
  }
}

Notice that we store raw numbers here. These represent pixels. We will convert them to rem units in our transformation script to ensure they respect the browser default font size settings.

The fluid typography math

Before we write the script we need to understand how clamp() works. The CSS clamp() function takes three values. It needs a minimum value, a preferred fluid value, and a maximum value.

The preferred value is the tricky part. We calculate it using the viewport width. We want the font size to start scaling up at our minimum viewport width and stop scaling at our maximum viewport width.

Let us assume our mobile viewport starts at 320px. Our desktop viewport stops at 1200px. We convert everything to rem units assuming a base of 16px.

Minimum viewport is 20rem. Maximum viewport is 75rem.

The formula for the preferred value involves finding the slope of the scale. We subtract the minimum font size from the maximum font size. We divide that by the difference between the maximum and minimum viewport widths. We then multiply that slope by the viewport width unit.

It sounds complicated but we can write a JavaScript function to handle the math for us.

Writing the custom transform

We need to tell Style Dictionary how to read our JSON and spit out CSS clamps. We do this by creating a custom build script.

Create a file named build.js in your project folder. We will define a custom transform that looks for our typography tokens and applies the fluid math.

const StyleDictionary = require('style-dictionary')

const minViewport = 20
const maxViewport = 75

function calculateClamp(minPx, maxPx) {
  const minRem = minPx / 16
  const maxRem = maxPx / 16

  const slope = (maxRem - minRem) / (maxViewport - minViewport)
  const intersection = -1 * minViewport * slope + minRem

  const preferredValue = `${intersection.toFixed(3)}rem + ${(slope * 100).toFixed(3)}vw`

  return `clamp(${minRem}rem, ${preferredValue}, ${maxRem}rem)`
}

StyleDictionary.registerTransform({
  name: 'typography/fluid',
  type: 'value',
  matcher: function(token) {
    return token.type === 'typography' && token.path.includes('max') === false
  },
  transformer: function(token, dictionary) {
    const path = token.path.slice(0, -1)
    const tokenGroup = dictionary.tokens[path[0]][path[1]][path[2]]

    const minPx = parseFloat(tokenGroup.min.value)
    const maxPx = parseFloat(tokenGroup.max.value)

    return calculateClamp(minPx, maxPx)
  }
})

This script registers a new transform. The matcher function makes sure we only process the min token. We ignore the max token so we do not generate duplicate CSS variables. The transformer function grabs both the minimum and maximum pixel values from the token group. It then passes them into our math function and returns the final clamp() string.

Configuring the build process

Now we need to configure Style Dictionary to use our new transform. We add this configuration directly to our build.js file.

const config = {
  source: ['tokens.json'],
  platforms: {
    css: {
      transformGroup: 'css',
      transforms: ['attribute/cti', 'name/cti/kebab', 'typography/fluid'],
      buildPath: 'build/css/',
      files: [{
        destination: 'variables.css',
        format: 'css/variables',
        filter: function(token) {
          return token.path.includes('max') === false
        }
      }]
    }
  }
}

const sd = StyleDictionary.extend(config)
sd.buildAllPlatforms()

We tell Style Dictionary to read from tokens.json. We set up a CSS platform. We include our custom typography/fluid transform in the transforms array. We also add a filter to the file output. This filter ensures that the max tokens do not get printed as separate CSS variables. We only want one CSS variable per heading level.

Run your build script from the terminal.

node build.js

The final output

Check your project folder. You will see a new build/css directory containing a variables.css file. Open it up and look at the generated code.

:root {
  --typography-heading-large-min: clamp(2rem, 0.836rem + 5.818vw, 4rem);
  --typography-heading-medium-min: clamp(1.5rem, 0.627rem + 4.364vw, 3rem);
  --typography-heading-small-min: clamp(1.125rem, 0.416rem + 3.545vw, 2rem);
}

You now have perfect fluid typography. The large heading will be exactly 32px on small screens. It will scale up smoothly as the screen gets wider. It will stop scaling when it reaches exactly 64px on large monitors. Everything is converted to rem units so it remains accessible.

You can drop these variables straight into your stylesheets.

h1 {
  font-size: var(--typography-heading-large-min);
}

h2 {
  font-size: var(--typography-heading-medium-min);
}

This approach saves hundreds of lines of CSS. You never have to write another min-width media query just to bump up a font size. Your components become much cleaner and easier to maintain. You also guarantee that the code exactly matches the design intent without manual calculations.

I honestly got so tired of manually copying token values and running these build scripts for every single project. Setting up the pipelines always took away hours of development time. So basically I built a plugin called Design System Sync to handle this automatically. It exports your Figma tokens directly to GitHub or Bitbucket via pull requests. It handles all the W3C formats and even does the CSS variable generation for you. You can check out the Design System Sync website or grab it directly from the Figma Community if you want to skip the manual setup entirely.

Stop exporting SCSS variables from your design system

Alexander — Sat, 25 Apr 2026 07:49:55 +0000

The breaking point

I was reviewing a pull request last Tuesday. A developer on my team was trying to implement a new theme switcher for our dashboard. They had imported a massive JSON file of design tokens from our repository. Then they wrote a giant JavaScript context provider to swap out the values dynamically on the client side.

I left a comment asking why they didn't just use native CSS variables. They replied that our design system pipeline only exported SCSS variables and raw JSON. That moment really cemented a thought I've been having for a long time. If you build products for the web, CSS variables are the only design token format you should care about.

Let's look at how most teams handle design tokens right now. A designer updates a colour in Figma. An automated script pulls that data via an API. The script runs it through a massive transformation pipeline. Then it spits out a dozen different files. You get SCSS variables. You get Less variables. You get a JavaScript object. You get a TypeScript interface. It feels like you are covering all your bases and being incredibly thorough.

But this creates a massive headache for the developers actually building the product. When you give people too many options, they often pick the wrong one for the job.

The problem with compiled tokens

Take SCSS variables as an example. They are entirely static. They compile at build time and then they are gone forever. If you want to support a dark mode using SCSS variables, you have to write twice as much CSS. You end up overriding classes or generating multiple massive stylesheets.

$color-bg-light: #ffffff;
$color-bg-dark: #121212;

.card {
  background-color: $color-bg-light;
}

body.dark-mode .card {
  background-color: $color-bg-dark;
}

This approach is exhausting. It bloats your compiled CSS completely unnecessarily. It makes maintaining UI components a total nightmare. Every single time you add a new element, you have to remember to write the specific dark mode override for it.

Now look at native CSS custom properties. They are incredibly dynamic. They live natively in the browser. They actually understand the cascade. You define your tokens exactly once at the root level. Then you redefine them for your dark theme. Your actual component CSS never has to change at all.

:root {
  --color-bg: #ffffff;
}

[data-theme="dark"] {
  --color-bg: #121212;
}

.card {
  background-color: var(--color-bg);
}

The component just asks for the background colour. The browser figures out which value to use based on the context. This is fundamentally better. It is cleaner. It requires significantly less code.

The debugging nightmare

There is another massive benefit that people completely ignore. I am talking about debugging.

Imagine you are trying to figure out why a button looks wrong on staging. You open Chrome DevTools. If your team uses a JavaScript theme provider or compiled SCSS, inspecting the button just shows a raw hex code. You see #007bff applied to the background. You have absolutely no idea which design token that maps to. You have to go search your codebase for that specific string.

If you use CSS variables, DevTools tells you the exact story. You inspect the button and see var(--button-primary-bg). You know exactly what token is driving the design. You can even click it in DevTools to see where the value is defined and test out changes right there in the browser.

What about utility frameworks?

I hear this specific complaint all the time. People tell me they use Tailwind CSS, so they don't need CSS variables. They just map their JSON tokens straight into their configuration file.

Honestly, that is a missed opportunity. You should absolutely plug your design tokens into your utility framework. But you should configure your Tailwind theme to consume your CSS variables, not raw hex codes. This lets you keep all the benefits of utility classes while letting the browser handle theme switching automatically via the cascade. You don't need to write dark:bg-gray-900 on every single div. You just write bg-surface and let the CSS variable change its own value based on the theme data attribute.

The native app argument

Now I know what some of you are thinking. You are going to say that your company also builds native iOS and Android applications. You need your design tokens in Swift and XML formats.

That is a completely fair point. If you actually deploy native mobile apps, you absolutely need those native formats. But tbh, most teams aren't doing that. Most teams are building web applications. They build dashboards and marketing sites. Yet they still copy the complex architectural patterns used by massive tech giants. You don't need a multi platform token pipeline if you only ship to the web.

Keeping it simple

So what do you actually do about this. You simplify your architecture. You cut out the middleman entirely.

You should export your Figma variables straight to CSS. You skip the massive JSON parsing scripts. You skip the complex build steps. You just get the CSS variables directly into your codebase.

This is exactly why I built the Design System Sync plugin. I wanted a way to skip all that painful boilerplate. The plugin takes your Figma design tokens and exports them directly to GitHub or Bitbucket via automatic pull requests. You can export standard W3C Design Tokens if you need them. But more importantly, you can export perfectly formatted CSS variables right out of the box. It handles multiple modes like light and dark themes automatically.

You can check out the plugin on Figma Community right here: https://www.figma.com/community/plugin/1561389071519901700?utm_source=devto&utm_medium=post&utm_campaign=bot

Or you can read more about how the GitHub integration works on the website: https://ds-sync.netlify.app?utm_source=devto&utm_medium=post&utm_campaign=bot

We really need to stop fighting the browser. Stop writing complicated JavaScript to do a job that CSS handles natively. Stick to custom properties. Your components will be smaller. Your debugging process will be faster. Your developers will be much happier.

Are you still forcing your team to use compiled SCSS variables for design tokens?

Export Figma variables to CSS custom properties using Style Dictionary

Alexander — Wed, 15 Apr 2026 15:00:36 +0000

TL;DR: We are going to take raw JSON from Figma variables and automatically turn it into working CSS custom properties using Style Dictionary.

The problem

Picture this. You are building a new component. You open Figma to check the design. You click on a button and see it uses a specific blue. You copy the hex code. You paste it into your CSS file.

Then the designer decides that blue is actually a bit too dark. They update it in Figma. But your code still has the old hex value. You do not find out until someone complains that the staging environment looks weird.

This happens all the time. Keeping code in sync with design is a massive headache. Tbh it is usually the worst part of building a UI. You just want to write logic and layout. You do not want to be a human copy machine for hex codes.

The good news is we can fix this. Figma lets you use variables for colours and spacing. We can take those variables as JSON and convert them directly into CSS. No more manual copying.

What you need

You only need a few things to follow along. Make sure you have Node.js installed on your machine. We are going to use a tool called Style Dictionary. It is an amazing open source package. It takes raw design data and formats it for any platform. We will focus on CSS today.

Open your terminal and create a new folder for this project.

mkdir figma-to-css
cd figma-to-css
npm init -y
npm install style-dictionary

Step 1: The raw data

First we need some data to work with. When you export variables from Figma they usually come out as a JSON file. The format often follows the W3C Design Tokens draft specification.

Let us create a fake export file to play with. Create a file called tokens.json in your project folder.

{
  "color": {
    "primary": {
      "value": "#0052CC",
      "type": "color"
    },
    "background": {
      "value": "#FFFFFF",
      "type": "color"
    },
    "text": {
      "value": "#172B4D",
      "type": "color"
    }
  },
  "spacing": {
    "small": {
      "value": "8px",
      "type": "dimension"
    },
    "medium": {
      "value": "16px",
      "type": "dimension"
    },
    "large": {
      "value": "24px",
      "type": "dimension"
    }
  }
}

This is a very simple example. Real Figma exports will be much bigger. But the structure is the same. You have categories like colour and spacing. Inside those you have your actual values.

Step 2: Setting up the build script

Now we need to tell Style Dictionary what to do with this JSON file. We need a configuration file. Create a new file called build.js in your folder.

We are going to write a short Node script. This script will read our JSON and output a nice CSS file.

const StyleDictionary = require('style-dictionary');

const config = {
  source: ['tokens.json'],
  platforms: {
    css: {
      transformGroup: 'css',
      buildPath: 'build/css/',
      files: [{
        destination: 'variables.css',
        format: 'css/variables'
      }]
    }
  }
};

const sd = StyleDictionary.extend(config);
sd.buildAllPlatforms();

Let me explain what is happening here. First we import the library. Then we define our configuration object.

The source array tells it where to find our JSON files. You can have multiple files here.

The platforms object is where the magic happens. We defined a CSS platform. The transformGroup tells Style Dictionary to use its built in rules for CSS. This handles things like converting names to kebab case.

The buildPath is where the final file will be saved. Finally the files array tells it exactly what to name the output file and what format to use.

Step 3: Running the build

We just need to run our script now. Go back to your terminal.

node build.js

You should see a message saying the build was successful. Check your project folder. You will see a new build folder. Inside that is a css folder. And inside that is your variables.css file.

The output

Let us look at what Style Dictionary actually generated. Open the variables.css file.

/**
 * Do not edit directly
 * Generated on Fri Oct 20 2023
 */

:root {
  --color-primary: #0052CC;
  --color-background: #FFFFFF;
  --color-text: #172B4D;
  --spacing-small: 8px;
  --spacing-medium: 16px;
  --spacing-large: 24px;
}

Look at that. It took our nested JSON and flattened it out. It added the CSS custom property syntax automatically. It even added a comment warning people not to edit the file directly.

You can now import this CSS file into your main project. When you use --color-primary in your styles it will perfectly match the Figma design.

Handling dark mode

You are probably thinking about dark mode now. Most modern apps need it. Figma handles this using variable modes. You might have a light mode and a dark mode in Figma.

When you export that data you usually get two different JSON files. Or you get one big file with different themes inside. Style Dictionary can handle this perfectly. You just create different source files for each theme. Then you output them to separate CSS files or scope them to specific CSS classes.

Here is a quick example of a dark mode JSON file. Let us call it tokens-dark.json.

{
  "color": {
    "background": {
      "value": "#172B4D",
      "type": "color"
    },
    "text": {
      "value": "#FFFFFF",
      "type": "color"
    }
  }
}

You can update your build script to output a variables-dark.css file too. Then you just load the right CSS based on the user preference. It makes theming incredibly easy to manage.

Automating the whole thing

So basically this script is great. But you still have to get the JSON out of Figma manually. You have to download it and put it in your folder. That still leaves room for human error. I actually got tired of doing this exact workflow. So I built a plugin called Design System Sync to completely automate it. It connects Figma directly to your GitHub or Bitbucket repo. When a designer changes a variable in Figma the plugin automatically generates a pull request with the updated CSS files. You can check it out at ds-sync.netlify.app or find it directly on the Figma Community. It uses the exact W3C formats we just talked about.

Try setting up Style Dictionary in your next project. It honestly changes how you think about CSS architecture.