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 give 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. A project on this system makes no 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 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 the story regenerates the specimen. The hand-off carries evidence, not a second interpretation.

One contract, whichever route a project takes

Three layers, and a surface takes whichever one it needs. Each one rests on 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) the surface needs a value 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 takes.

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. The shell, search, navigation and publish workflow stay in place.

Copy the example project