FSE Documentation

Useful LInks:

Documentation of the core-fse parent theme and its design-system contract.

Related docs

  1. Design-System:
  2. theme.json — editor settings and WordPress presets.
  3. Child theme — the required contract and the Benedictine example.
  4. Public API reference — available public values.
  5. Limitations and technical details — WordPress workarounds and compatibility.

Purpose

core-fse is a parent Full Site Editing theme. It provides the shared design system, Gutenberg settings, and base CSS layer for sites implemented as child themes.

Every production child theme:

  • declares Template: core-fse;
  • inherits its parent theme.json settings;
  • defines its own brand values;
  • can extend the palette, fonts, gradients, shadows, and global styles;
  • compiles core-fse CSS into its own CSS bundles.

The documentation is normative guidance for developers, but the ultimate sources of truth remain:

  • assets/css/vars/*.css;
  • assets/css/*.css;
  • theme.json;
  • the code of an actual child theme.

What the design system includes

  • two token layers: Primitive and Semantic;
  • an overridable Core contract;
  • public WordPress presets from theme.json;
  • base frontend and editor styles;
  • child-theme inheritance and extension rules;
  • fluid typography and spacing;
  • shared accessibility rules.

Not included:

  • detailed custom-block architecture;
  • PHP/JS theme infrastructure that does not affect the design contract;
  • the Global Styles administrative custom-CSS editor;
  • automatic Figma synchronization.

Sites are built from WordPress core blocks and custom blocks. Both block types must use the same public design-system API.

CSS styles priority

Priority for CSS consumers:

  1. a WordPress preset;
  2. a Semantic/Core variable;
  3. a plain CSS value for a unique case.

Primitive variables are not a public API.

CSS Unit policy

  • Use WordPress presets and public design-system variables whenever a suitable
    value exists.
  • If a fixed custom value is unavoidable, use rem, em, %, viewport units,
    or another context-appropriate relative unit.
  • Do not hardcode layout, spacing, sizing, positioning, or typography in px.
  • Use px only where a physical pixel boundary is intentional, such as a
    1px border or separator.
  • Do not set letter-spacing unless the design clearly requires a meaningful
    deviation from inherited theme typography. It must not be added as a default
    styling habit.
  • For font-size, always use an existing
    var(--wp--preset--font-size--*) value. A percentage may be used for an
    intentional relative adjustment. Do not hardcode font sizes in px, rem,
    or em.
TaskUse
Palette colorvar(--wp--preset--color--*)
Spacing from the system scalevar(--wp--preset--spacing--*)
Font size from the system scalevar(--wp--preset--font-size--*)
Child-theme font familyvar(--wp--preset--font-family--*)
Radius, line height, letter spacingsemantic variable
Z-index or motionsemantic variable
Site brand settingoverride the Core contract in the child theme
Unique grid/layout constructionplain CSS
/* Correct */
.card {
  padding: var(--wp--preset--spacing--fluid-md);
  border-radius: var(--radius-medium);
}

/* Incorrect: a primitive has become the component API */
.card {
  padding: var(--size-fluid300-16px);
}