Link editor presets to CSS variables

Linked presets let editor content follow your theme settings. Instead of saving a fixed value such as 32px, the editor saves a CSS reference such as var(--heading-size). When the theme value changes, every linked use updates without editing the content again.

Define a theme setting

Create settings in config/settings_schema.json. The editor looks up each control’s presets by group name, matched exactly — Typography and type do not match typography:

Group	Used for
`typography`	Text-size presets
`color_schema`	Color presets
`corner_radius`	Corner-radius presets
`padding`	Spacing presets
`custom_font_sizes`	Additional text presets
`custom_colors`	Additional color presets

{
  "name": "typography",
  "settings": [
    {
      "type": "range",
      "id": "heading_size",
      "label": "Heading size",
      "min": 24,
      "max": 72,
      "step": 1,
      "default": 40,
      "unit": "px",
      "role": "heading"
    }
  ]
}

Connect the setting to a CSS variable

Declare a CSS custom property in layouts/theme.liquid and read the setting into it:

{% style %}
  :root {
    --heading-size: {{ settings.heading_size | append: 'px' }};
  }
{% endstyle %}

A setting with no CSS variable is not offered as a preset. The editor builds each preset menu from the settings in the group that resolve to a variable, and silently skips the rest. A group of eight colors with variables declared for three shows three presets. Two conditions make a declaration count:

It sits inside a {% style %} or <style> block.
It is a custom property reading the setting: --anything: {{ settings.heading_size }}.

A {{ settings.heading_size }} anywhere else — a meta tag, an inline style attribute, or a plain font-size: output — renders the value but registers no variable, so the preset does not appear. The variable name does not need to match the setting ID. The link comes from the settings.heading_size reference. Matching them is still worth doing: when the editor writes a variable for a setting it manages, it names it --<setting_id>, and matching keeps one convention in the file. When the editor links the preset, it saves the complete var() expression:

font-size: var(--heading-size);

It never saves the bare token --heading-size as a property value.

Make presets responsive

Keep the saved content linked to one variable and change the variable in the cascade:

:root {
  --content-gap: 12px;
}

@media (min-width: 768px) {
  :root {
    --content-gap: 24px;
  }
}

Content that uses var(--content-gap) now adapts without separate mobile and desktop content.

Control typography

Each typography preset can resolve size, family, and weight independently. For the schema rules behind these presets — which group becomes preset cards, what separates a preset from a font or a weight, and which setting types the theme panel renders — see writing settings schema. For new size settings, use role: "heading" or role: "body". Existing setting IDs that begin with font_size_h continue to behave as headings when no role is present. Use explicit references when a size preset should follow separate font settings:

{
  "type": "range",
  "id": "heading_size",
  "label": "Heading size",
  "default": 40,
  "unit": "px",
  "role": "heading",
  "font_family_ref": "heading_font",
  "font_weight_ref": "heading_weight"
}

The editor resolves each dimension in this order:

Family: explicit reference, literal value, then the font for the setting’s role.
Weight: explicit reference, literal value, then the default for the role.
Size: the setting value and its unit, defaulting to px.

An explicit reference links to a variable when one is declared. A literal stays a literal. Once a merchant applies a text preset to content, the editor maintains a variable for the preset itself and links content to that instead:

--heading_size_font_family: var(--heading-font);

Content styled with the preset records var(--heading_size_font_family) — named for the preset, not for the font it uses today. Repointing the preset to another font rewrites that one declaration, and every piece of content already styled with it follows. Read the same variable in your own CSS, with the referenced setting as a fallback:

h1 {
  font-family: var(--heading_size_font_family, var(--heading-font));
}

Reading var(--heading-font) alone is the most common reason a merchant repoints a preset and the theme’s own headings do not move.

Understand value precedence

The editor chooses the first available value:

An unsaved value in the theme panel
The saved theme value
The setting’s schema default
The editor fallback

Unsaved values reach the text and color preset menus in the rich-text toolbar, so those follow live theme edits before you save. The corner-radius, spacing, and section-level color controls read saved values, so a new setting or a changed value appears there only after you save the theme.

Link radius and padding

Put radius and spacing settings in the corner_radius and padding groups. Declare a CSS variable for each setting:

{% style %}
  :root {
    --card-radius: {{ settings.card_radius | append: 'px' }};
    --section-gap: {{ settings.section_gap | append: 'px' }};
  }
{% endstyle %}

When linked, radius and padding controls store var(--card-radius) and var(--section-gap). A linked all-sides control applies the selected preset to every side or corner.

Unlink a preset

Choose Manual Settings in a preset menu when one content item needs a fixed value. The editor resolves the current CSS values and exposes the individual controls. Choose Link Variables to return to the theme-driven preset workflow. Add Preset saves the current values as a new preset instead.

Prefer linked values for your design system. Unlink only intentional exceptions, because fixed values no longer follow later theme changes.

Troubleshoot linked presets

What you see	Why	Fix
A preset menu is empty, or shows No presets yet	No setting in that group resolves to a CSS variable	Declare `--x: {{ settings.<id> }}` inside a style block for each setting you want offered
Some settings in a group appear, others do not	The missing ones have no variable declared	Declare one per setting; the editor skips the rest silently
A group’s presets never appear	The group name does not match exactly	Use `typography`, `color_schema`, `corner_radius`, or `padding` verbatim
A new theme setting is missing from a radius or spacing menu	Those menus read saved values	Save the theme, then reopen the control
A merchant repoints a text preset and your headings keep the old font	Your CSS reads the referenced setting’s variable directly	Read the preset’s own variable, with the setting’s as a fallback
Content keeps a fixed value after a theme change	That item was switched to Manual Settings	Choose Link Variables on the item

When a preset menu is empty, merchants apply values by hand and the content stops following the theme — so treat a missing variable as a bug in the theme, not a limitation of the editor. For the broader configuration flow, see root theme configuration. For the schema shape these presets are built from, see writing settings schema.

Get Started

Core Concepts

Guides

Migration guides

Website & Themes

FairShare SDK

Files SDK

Portal & Widgets

Link editor presets to CSS variables

Define a theme setting

Connect the setting to a CSS variable

Make presets responsive

Control typography

Understand value precedence

Link radius and padding

Unlink a preset

Troubleshoot linked presets

​Define a theme setting

​Connect the setting to a CSS variable

​Make presets responsive

​Control typography

​Understand value precedence

​Link radius and padding

​Unlink a preset

​Troubleshoot linked presets

Define a theme setting

Connect the setting to a CSS variable

Make presets responsive

Control typography

Understand value precedence

Link radius and padding

Unlink a preset

Troubleshoot linked presets