Decide where the pages of a Core dna site are composed before writing code: on the platform, in your own application, or on the platform with a few pieces filled in by the browser. The decision tree, each shape in depth, multi-brand and languages, and a table and case studies to make the call.
L2
Unit 05 · Multi-brand and multi-language
Per-brand design tokens
Multi-brand and multi-languagePage 23 of 29Updated
Theme every brand from CSS custom properties so one build serves them all. How a page selects its brand's token set with one attribute, and how per-brand values in site data are keyed when several hostnames share a site.
Who this is for. The developer styling one codebase for several brands. After this page you can switch every brand's colours and fonts with one attribute, keep one stylesheet build for all of them, and key values an administrator controls by brand.
One build for every brand
A stylesheet forked per brand multiplies the build: every brand is another entry to compile, and every shared fix is built into each of them. CSS custom properties are resolved by the browser instead, so one build serves every brand and a new brand is a set of values. Design tokens as custom properties in Guide 3 covers the token pattern itself: printing values from site data, which source wins, the stylesheet per brand it replaces, and what custom properties cannot do. This page adds the part that belongs to several brands: choosing which set of values applies.
The attribute that selects a brand
Set a data-brand attribute once, high in the page, from the brand key; Per-brand template folders shows how the key is worked out from the hostname. The stylesheet defines the default values on :root and each brand's overrides under its attribute, and components use only the tokens:
Every element inside body inherits the brand's values, so components carry no brand logic and the stylesheet is the same file for every brand. A brand with no rule of its own uses the :root defaults.
Per-brand values from site data
When an administrator should control a brand's values without a build, keep them in site data, as Guide 3 shows. Its examples hold one set of tokens per site in a JSON entry named styles. With several hostnames on one site, nest one set per brand key in the same entry:
{% set allTokens = _siteData.get('styles') %}
{% set tokens = allTokens[brandKey]|default({}) %}
<body data-brand="{{ brandKey }}"{% if tokens is iterable and tokens is not empty %} style="{% for name, value in tokens %}--{{ name|e('html_attr') }}:{{ value|e('html_attr') }};{% endfor %}"{% endif %}>
With a site per brand, each site keeps its own styles entry and Guide 3's snippet works unchanged. Site data is read from the site first and then from the client, so values every brand shares can sit once at client level.
Which value wins
The order is the one Guide 3 describes: site data first, then the template, then the record, with the most specific source winning. Custom properties give that order through the cascade, because a value set on an element overrides one set on its parent. A site whose markup cannot rely on the cascade merges the three sets in the same order before printing, skipping any name a higher source has already set, and prints the result once. The outcome is the same.