Design Language System
Corex ships a Design Language System (DLS): one organized, documented vocabulary for building sites — so a developer or designer always knows what exists, how to use it, and when not to. It is WordPress-native by principle: a custom block exists only where Corex needs reusable server-rendered data, accessibility behavior, or a repeated agency pattern core cannot express. Everything else is a documented core block, a Corex block style, a design token, or the runtime.
The taxonomy
Section titled “The taxonomy”| Layer | What it is | Where |
|---|---|---|
| Foundations | Design tokens (color, type, spacing, shadow, radius, layout, motion, focus, z-index) + guidelines (RTL, a11y, focus, motion, icons) | theme.json + docs |
| Components | UI atoms — alert, badge, breadcrumbs, modal, card, button, … | corex-ui (blocks + block styles), core blocks, runtime |
| Patterns | Composed sections — hero, features, stats, FAQ, CTA, contact, … | corex-ui PatternLibrary |
| Templates | FSE page types — landing, contact, form, plus the defaults | the theme |
| Client readiness | Minimum company-site needs mapped to native Corex/WordPress mechanisms | CLI readiness matrix + docs |
| Gap analysis | The evidence: every candidate UI element → one decision | docs |
The catalog (Corex\Ui\DesignSystemCatalog) enumerates this taxonomy in code and is drift-checked against the
real registered corex/* blocks — it can never list a Corex block that does not exist.
Principles
Section titled “Principles”- Token-only — every component consumes
theme.jsonCSS custom properties; a rebrand is configuration, not a recompile (brand.jsonoverrides at runtime). - RTL-first — logical CSS properties; Arabic layouts are correct by default.
- Accessible (WCAG 2.2 AA) — state conveyed beyond color, keyboard-operable, visible focus, correct ARIA.
- Native-first — see the client-readiness matrix and gap analysis for what is a core block, a block style, a pattern, or a Corex block, and why.