Help Center
Brand DNA and Component Classes
How brand tokens flow into every rendered page, and how shared ss- component classes keep buttons, headings, and badges consistent site-wide.
Seedly Sites is built around a simple idea: define the brand once, and let every page inherit it. Two layers make that work - brand tokens and a per-site library of shared component classes.
Brand Tokens#
The colors and fonts you set in Site Settings compile into the site's design tokens, which drive:
- the published site (rendered pages reference the tokens, not hardcoded hex values),
- the preview, and
- the builder canvas, so an element styled "Primary" in the builder shows the real brand color while you edit.
When an element offers a brand-aware style option (a Section's background style, a Button's color variant), prefer it over typing a hex value. Change the primary color in Settings and every token-driven element updates in one move; a hardcoded hex value stays stale forever.
The ss- Component Library#
Real brands repeat components: the same CTA button shape, the same uppercase section heading, the same eyebrow badge above headings. Styling each instance by hand drifts apart over time.
The platform's answer is a small set of vetted, named CSS classes with an ss- prefix, stored in the site's Custom CSS and applied to elements through the Class field in the builder's Advanced settings. Because every instance shares the one class, editing that class updates all of them at once.
Classes the platform synthesizes today include:
| Class | Component |
|---|---|
ss-btn | The standard CTA button shape - one canonical padding, corner radius, and typography. Color still comes from the button's native brand style, so primary and secondary CTAs share the shape |
ss-h2 | The recurring uppercase section heading. Normalizes family, weight, and a consistent mobile size while leaving desktop sizes free per heading |
ss-cta-circle | The round CTA badge (a circular "Contact" or "Write Me" button) |
ss-badge | The eyebrow badge - the short highlighted label above a section heading |
ss-faq | FAQ accordion typography matched to the brand |
Where the Library Comes From#
When you port an existing site, the migration pipeline harvests the source site's brand identity - palette, typography scale, button shape, badge and FAQ styling - and synthesizes the ss- classes from those measured values. The result is written into the site's Custom CSS, so a migrated site arrives already carrying its own design system rather than a pile of one-off styles.
For a site you build by hand, you can create the same kind of library yourself: define shared classes in Settings, Custom CSS, then apply them via the Class field.
The classes are deliberately color-agnostic where possible. They reference the brand tokens (or leave color to the element's native style option), so re-branding the site does not require touching the component CSS.
The Workflow to Follow#
- Set brand colors and fonts in Settings, Branding
- Style individual elements with their native fields first (Section style, Heading size and level, Button variant)
- When a styled pattern repeats across pages, promote it: define one
ss-class in Settings, Custom CSS - Apply the class to each instance via the element's Class field (Advanced settings)
- To restyle the pattern later, edit the one class - every instance follows
What to avoid:
- Per-element custom CSS for repeated patterns. Ten hand-styled buttons are ten chances to drift. One class is one source of truth.
- Hardcoded brand colors. Use the native brand style options or token-driven classes so a palette change propagates.
Summary#
| Layer | Lives in | Changes propagate by |
|---|---|---|
| Brand tokens | Settings, Branding (colors, fonts) | Editing the setting |
Component classes (ss-) | Settings, Custom CSS + each element's Class field | Editing the one class |
| Per-element styling | The element's native fields in the builder | Editing that element only |