Skip to content
TYPO3Soul Design System

One system, from design to delivery

Soul gives TYPO3 community projects a shared visual language for product pages, documentation and interface code — so every hand-off starts from the same decisions.

Start with measured screens and rendered components. Publish from reStructuredText or Markdown. Ship plain classes or web components. Every route resolves to the same tokens and the same markup contract.

Design system

Design with Claude

Give Claude the written guidelines, rendered components and finished screens it needs to design with the same system developers ship.

Start designing with Claude
For documentation teams

Publish documentation as part of the product

Turn reStructuredText or Markdown into a site whose navigation, search and content components already belong to the interface around it.

Publish a first site
For developers

Ship the interface without a framework

Link the class layer directly, then add the custom elements where a surface needs behaviour. Server-rendered markup remains the contract.

Build a first surface

Built for community projects

Soul serves the extensions, tools, services and documentation sites that the TYPO3 community builds around the CMS.

Soul covers the surfaces those projects use to present themselves, explain their work and provide an interface: product pages, guides and application UI belong to the same system.

Soul does not define the TYPO3 backend, typo3.org or another official TYPO3 surface. Those products have their own owners and design rules, and adopting this system is not a claim on any of them.

The same decisions survive every hand-off

Design systems often stop at a design file or a component library. Soul keeps the design evidence, the documentation renderer, the class vocabulary and the elements connected to the same sources.

Across community projects

Readers keep their bearings

Product pages, guides and working interfaces use the same navigation, type, controls and states. The next project feels familiar before its content is familiar.

Across design and code

Changes keep their source

A colour changes in a token, a component changes in its element, and a specimen is regenerated from the story. The hand-off carries evidence instead of a second interpretation.

One contract, whichever route a project takes

Three layers, and a surface reaches for whichever one it needs. Each is written in terms of the one under it, so a page that mixes them is still one system.

Layer Written as Reach for it when
Tokens var(--surface-raised) a value is needed at all
Classes class="sds-card" a server produces the markup
Elements <sds-note tone="warn"> the surface has behaviour or state

As a standalone frontend says what each layer holds and which of them a given surface should be written in.

Start where the work is

The system does not ask every project to adopt the same toolchain. It asks each toolchain to speak the same visual language.

Design system

Explore the rules and their specimens

See the colour, type, spacing, state and brand decisions beside the rendered evidence that keeps each rule concrete.

Explore the design system
Put it to work

Render a project of your own

Start from a complete Guides project, then replace its content while the shell, search, navigation and publishing workflow stay in place.

Copy the example project