Stop Building Pages.
Start Building Systems.

Every designer on a project has one of two internal monologues when they start working:

The page-builder produces a site that looks right today. The systems thinker produces a site that stays right forever — no matter how many pages are added, no matter which team member works on it, and critically: no matter how many different clients use the same underlying system.

Why manual styling feels faster — and why it isn't

When you are new, manual styling feels faster because the feedback is immediate. You click, you see a result, it looks right. There is no planning overhead. But you are spending time instead of saving it. Every pixel you type by hand is a debt that must be repaid — when the client changes their brand, when you onboard a new team member, when you add 20 more pages.

Systems thinking has a setup cost and an exponential return. The graph inverts around week 3 of a project, and by month 2 you are building pages in a fraction of the time a manual-styler would need.

Craft is not a style library. It is a set of conventions, CSS variables, and token standards that make Webstudio projects fast, maintainable, and shareable — regardless of what brand or client is using them.

That last part is crucial. Craft does not tell you what colours to use. It tells you where to put your colours, and what to name them, so that any section template built to Craft standards can be dropped into any client project and automatically inherit that client's brand.

Craft in 3 sentences

• CSS variables define your site's values — colours, spacing, sizing — in one place called Global Root.
• Tokens are named style bundles applied to elements. They reference those variables, not hardcoded values.
• Templates from the Craft Library use only those variables, so they adapt to any brand automatically.

How to get started with Craft

1. Go to Marketplace → Pages → Craft and insert the Style Guide page.
2. Open Global Root and customise the CSS variable values to match your client's brand.
3. Map the semantic variables (--foreground-primary, --background-primary, etc.) to your brand colours.
4. Start building using those predefined variables — never by hardcoding values.

Craft's page structure standard

Every Craft project follows this navigator structure:

/* Craft standard page structure (from the docs) */
Page Wrapper
  Slot
    Global Styles    /* CSS variables live here */
    Nav
  Main
    Section Hero     /* prefix sections with "Section " */
      Container       /* uses the "container" token */
    Section Services
      Container
  Slot
    Footer

Craft defines a specific set of CSS variables. These are the only variables your tokens should reference for colour and spacing. You set their values in Global Root once per project. Here they all are:

Foreground variables — text, icons, borders

Background variables — surfaces, cards, pages

Spacing variables — gaps and rhythm

Interaction variables

This is where most beginners make their first big mistake. They pick a colour because it looks right — without asking what role that colour is playing.

Foreground = what sits on top. Text, icons, borders, outlines — anything drawn over a surface.
Background = the surface itself. The page, a card, a section, a button face.

Why this matters — the dark mode proof

Craft's system lets you flip an entire site from light to dark mode by changing ~6 variable values. This only works if every element is using the right semantic token for its role.

/* Light mode — set in Global Root */
--foreground-primary:  #050a1e;  /* dark text */
--background-primary: #f4f3f0;  /* light page */
--background-card:     #ffffff;   /* white card */

/* Dark mode — change only these values */
--foreground-primary:  #f4f3f0;  /* light text ← flipped */
--background-primary: #050a1e;  /* dark page ← flipped */
--background-card:     #0a1540;  /* dark card ← flipped */

/* Every element that used var(--foreground-primary) updates. */
/* Every element that used var(--background-card) updates. */
/* Elements with hardcoded colours: nothing. They stay wrong. */

Common mistakes

The practical rule

Before choosing any token for a colour property, ask one question: "Is this element drawn ON TOP of something, or IS it the surface?" If on top → foreground token. If it is the surface → background token.

Craft distinguishes between two types of tokens. This is official Craft doctrine — not opinion.

The naming rule you need to memorise

Utility tokens describe what they do. container creates a max-width container. margin-auto centres an element. The name is the instruction.

Semantic tokens describe what something IS. Card means this element IS a card — a content container with a background, padding, and border. The name is the identity.

One of the most common questions is: "Should I make this a token or just style it locally?" Craft's documentation gives a clear answer.

The practical questions to ask

1. Will I use this combination of styles more than once? If yes → token.
2. Is this a single property? If yes → CSS variable directly, or Local.
3. Is this a simple toggle like text-align or display flex? Use the Style Panel button, not a token.
4. Would a new team member need to understand this to work on the project? If yes → it needs a name → token.

This is one of the most misunderstood areas of CSS. Most beginners use px for everything because it's predictable. But this breaks accessibility, creates rigid layouts, and makes responsive systems harder than they need to be.

px — absolute, rigid, ignores user preferences

px is a fixed pixel value. 16px is always 16px, regardless of the browser font size setting, the viewport, or the parent element. It does not scale. It does not respond to accessibility settings where a user has set their browser default font to larger.

rem — root-relative, accessible, preferred for font sizes and spacing

rem stands for "root em." It is always relative to the html element's font size (16px by default). If a user has set their browser to a larger default font (for accessibility), your rem values scale automatically. This is why Craft uses rem for all its spacing variables.

/* Use rem for: */
font-size:   1rem;    /* 16px — scales with user preferences */
padding:     1.5rem;  /* 24px — consistent, accessible */
margin:      2rem;    /* 32px */
gap:         var(--gap-m);  /* Craft handles the rem value for you */

/* Open Props size scale uses rem: */
--size-3:    1rem;     /* 16px */
--size-5:    1.5rem;   /* 24px */
--size-7:    2rem;     /* 32px */

em — parent-relative, useful for component-internal spacing

em is relative to the current element's font size (or its closest parent that sets a font size). This makes it useful when you want spacing to scale proportionally with the text inside a component — for example, a button's padding.

/* em is good for: internal component scaling */
.button {
  font-size:  1rem;
  padding:    0.6em 1.5em;  /* scales with the button's own font-size */
}
.button-large {
  font-size:  1.25rem;
  /* padding automatically scales — no override needed */
}

% — relative to parent, essential for fluid layouts

% is relative to the parent element for widths, and to the element itself for padding-top/bottom percentage values. It is the foundation of fluid, responsive layouts.

/* % for fluid widths */
width:      100%;    /* fill the parent — the basis of all responsive grids */
max-width:  50%;     /* maximum half the parent */

/* % for aspect ratios (the padding-top trick) */
padding-top: 56.25%; /* = 16:9 ratio (9/16 = 0.5625) */

The decision rule

Once you understand units, calc() and clamp() unlock a new level of responsive design — sizes that respond to the viewport without needing breakpoints.

calc() — combine units and do arithmetic

calc() lets you mix different unit types in a single expression. This is impossible otherwise — you cannot write 100% - 2rem in plain CSS without it.

/* Typical uses of calc() */
width:      calc(100% - 2rem);   /* full width minus 1rem margin each side */
height:     calc(100vh - 75px);  /* full viewport minus nav height */
padding:    calc(var(--gap-m) * 1.5);  /* 1.5× a Craft variable */
margin-top: calc(var(--size-8) + 2rem);

/* Craft uses calc() in its fluid spacing variables: */
--gap-m:    var(--size-fluid-4);
/* which is: */
--size-fluid-4: clamp(2rem, 4vw, 3rem);

clamp() — fluid values between a minimum and maximum

clamp(min, ideal, max) sets a value that scales fluidly between two limits. The ideal value (usually a vw unit) grows with the viewport, but is always constrained between min and max.

/* clamp(minimum, ideal-fluid, maximum) */
font-size:  clamp(1rem, 2.5vw, 1.5rem);
/*          ↑ never smaller  ↑ fluid  ↑ never larger */

/* Open Props uses clamp() throughout — this is from Craft's variable set: */
--font-size-fluid-1:  clamp(1rem, 4vw, 1.5rem);
--font-size-fluid-2:  clamp(1.5rem, 6vw, 2.5rem);
--size-fluid-3:       clamp(1.5rem, 3vw, 2rem);

/* container max-width (from Craft): */
--container-max-fluid: clamp(285px, 90%, 1350px);
/*  never narrower than 285px, never wider than 1350px, 90% in between */

Setting a fixed width or height on an element is one of the most common ways to create a layout that breaks on different screens. Constraints are almost always better than fixed dimensions.

max-width — the container pattern

max-width lets content be fluid up to a limit, then stops growing. This is the foundation of the Craft container token.

/* ❌ Fixed — breaks on small screens, looks odd on very wide screens */
width: 1200px;

/* ✅ Fluid with constraint — the container pattern */
width:     100%;
max-width: var(--container-max-fluid);  /* clamp(285px, 90%, 1350px) */
margin:    0 auto;    /* centre it */

/* Reading width constraint (line length comfort) */
max-width: 65ch;  /* ch = width of "0" character — great for text */

min-height — for sections and hero areas

min-height ensures a section is at least a certain height, but can grow to fit content. Never use a fixed height on a section that contains text — it will overflow on small screens or cut off dynamic content.

/* ❌ Fixed height — text overflows when it doesn't fit */
height: 500px;

/* ✅ Minimum height — grows with content */
min-height: 500px;
/* or: */
min-height: 60vh;   /* at least 60% of viewport height */
/* or: */
min-height: clamp(300px, 50vh, 700px);  /* constrained fluid */

max-height with overflow — for scrollable areas

/* Popup or dropdown — constrained height with scroll */
max-height:   85svh;      /* svh = small viewport height (mobile-safe) */
overflow-y:   auto;
/* Craft uses this pattern: */
--popup-max-height: 85svh;

Responsive design is not about adding breakpoints at the end. It is about using the right units and constraints from the beginning so that most layouts need very few breakpoint overrides at all.

The responsive mindset shift

Webstudio breakpoints — how Craft handles them

Webstudio uses max-width breakpoints by default. When you select a breakpoint like 991px, the canvas shows at 768px — this is intentional. You are styling for the minimum width of that breakpoint range, to catch edge cases.

The fluid-first toolkit

/* These four patterns cover most responsive needs: */

/* 1. Fluid container */
width: min(90%, 1200px); margin: 0 auto;

/* 2. Auto-fit grid — wraps automatically, no breakpoints needed */
display: grid;
grid-template-columns: repeat(auto-fit, minmax(min(300px, 100%), 1fr));

/* 3. Fluid typography */
font-size: clamp(1rem, 2.5vw, 1.5rem);

/* 4. Flexible padding */
padding: clamp(1rem, 5vw, 3rem);

Here is the most important practical demonstration of everything you have learned. Look at these two client builds — completely different brands, different colours, different energy. Both built in Webstudio. Both using the exact same Craft token structure.

The token names are identical across both projects. --background-card on Client A resolves to white. --background-card on Client B resolves to deep navy. The card component's token says var(--background-card) in both projects — the Global Root value is what makes them look different.

What you just saw — summarised

• One Craft section template = one set of token names
• Client A's Global Root = their brand values mapped to those token names
• Client B's Global Root = their brand values mapped to the same token names
• The template is brand-agnostic. The Global Root is where brand identity lives.
• This is how large agencies run 40+ projects simultaneously — one system, infinite skins.