Design-System Architecture

Core FSE as a parent theme

core-fse is the base parent theme for FSE sites. It does not provide the finished design for a specific brand. Its purpose is to provide:

• a stable set of Gutenberg settings;
• shared size scales;
• a required brand contract;
• semantic variables;
• base CSS for the frontend and editor;
• an inheritance and extension mechanism.

A child theme turns this foundation into a specific site design.

core-fse
├── primitive values
├── semantic values
├── Core contract
├── theme.json presets and editor settings
└── base CSS
          ↓ inheritance + CSS import
child theme
├── brand variable overrides
├── fonts, palette extensions and global styles
├── theme-specific CSS
└── final compiled bundles
          ↓
WordPress core blocks + custom blocks

System layers

1. Primitive

Internal calculated values in assets/css/vars/primitives.css.

The primary examples are fluid-size families and easing curves. A primitive has no UI meaning and must not be used as a standard component API.

2. Semantic

Shared semantic roles in assets/css/vars/semantic.css:

• font weights;
• line heights;
• letter spacing;
• radius;
• z-index;
• motion;
• shadows.

Semantic variables may be used in styles when no suitable WordPress preset exists.

3. Core contract

assets/css/vars/theme-core.css is not a third token layer, but the contract between parent and child themes.

It contains:

• required brand colors with fallback values;
• overridable aliases for spacing and large font sizes;
• breakpoints;
• runtime variables;
• helper variables for WordPress constraints.

4. WordPress preset API

theme.json exposes values in Gutenberg and generates CSS variables:

theme.json slug: fluid-md
        ↓
--wp--preset--spacing--fluid-md
        ↓
Gutenberg controls, block markup and CSS

This is the primary public API for colors, spacing, and font sizes.

5. Base CSS

• front.css — frontend-only rules;
• front-and-admin.css — shared frontend and editor-iframe rules;
• admin-block-editor.css — administrative-editor UI and fixes.

For details, see CSS architecture.

Value flow

Spacing example:

Primitive:
--size-fluid300-16px
        ↓
core-fse/theme.json:
slug = fluid-md
        ↓
WordPress:
--wp--preset--spacing--fluid-md
        ↓
Consumer CSS:
padding: var(--wp--preset--spacing--fluid-md)

Brand-color example:

Core contract fallback:
--color-accent: #851f5a
        ↓ override
Child theme vars.css:
--color-accent: #c10a27
        ↓ reference
Child theme theme.json palette:
slug = accent, color = var(--color-accent)
        ↓
--wp--preset--color--accent

Consumers

The design system is used by:

• core blocks WordPress;
• custom blocks;
• block patterns;
• templates and template parts;
• child-theme global styles;
• theme-specific CSS.

Custom-block implementation architecture is covered separately. Within this system, the important point is that custom blocks do not receive a separate parallel value scale.

Related but outside the system

core-fse also contains editor settings, a block allowlist, lazy loading, Navigation fixes, profilers, and other PHP/JS modules. They are parent-theme infrastructure, not design-system layers.

The Appearance → Global Styles module lets administrators save additional custom CSS. This is a runtime capability and possible late override, not a source of tokens or a standard way to evolve the design system.