Creating a Living Style Guide Page for Your HTML Template

What a Living Style Guide Actually Is

A living style guide differs from a static PDF or a Figma page in one critical way: it is rendered by the same browser, the same CSS, and the same JavaScript that power the real site. Change a Sass variable, rebuild, and the style guide updates automatically. Nothing goes stale because there is nothing to synchronise.

The term overlaps with UI pattern library and design system documentation, but the distinctions matter in practice. A pattern library catalogues reusable components. A design system adds governance: naming conventions, usage rules, accessibility requirements. A living style guide is the rendered, in-browser version of both. For most HTML template projects, a single well-structured page delivers all three at a scale that is actually maintainable by a team of one to five people.

When you are working from a premium template like the Canvas HTML Template, the component HTML, utility classes, and CSS custom properties are already defined. The style guide page is largely an exercise in surfacing what already exists, not inventing something new.

When Not to Build a Dedicated Style Guide Page

Be honest about scope before you commit. A living style guide pays off when:

• More than one developer or designer touches the codebase.
• The project runs for more than three months or has recurring maintenance phases.
• A client or stakeholder needs to approve the visual language before pages are built.
• You are theming a single template for multiple brands (a common agency workflow covered in detail in Theming One HTML Template for Multiple Client Brands with CSS Variables).

For a one-page landing site with a solo developer and a two-week timeline, the overhead probably exceeds the benefit. Recognising this upfront is part of working professionally.

File and Folder Structure

Keep the style guide inside the project rather than in a separate repository. A sensible location is styleguide/index.html. This file references the same compiled CSS and JavaScript as every other page in the project.

project-root/
├── css/
│   └── style.css          (compiled from Sass)
├── js/
│   ├── plugins.min.js
│   └── functions.bundle.js
├── styleguide/
│   └── index.html         (the living style guide page)
└── index.html             (site homepage)

The style guide page links to assets with relative paths one level up:

<link rel="stylesheet" href="../css/style.css">
<script src="../js/plugins.min.js"></script>
<script src="../js/functions.bundle.js"></script>

Because the style guide imports the production stylesheet, any change to a Sass partial is immediately visible after a rebuild. No separate watch task, no separate config.

If you are using a modern build tool, the post Gulp vs Vite vs Webpack for HTML Template Workflows covers how to configure Vite to watch multiple HTML entry points simultaneously, which makes this two-file approach trivial to maintain.

The Five Layers to Document

1. Colour Tokens

Render every CSS custom property as a swatch block so developers and clients can see the exact value and the variable name in one glance.

<div class="d-flex flex-wrap gap-3 mb-5">
  <div class="text-center">
    <div style="width:80px;height:80px;background:var(--cnvs-themecolor);border-radius:.5rem;"></div>
    <code class="d-block mt-2 small">--cnvs-themecolor</code>
  </div>
  <div class="text-center">
    <div style="width:80px;height:80px;background:var(--bs-body-bg);border:1px solid var(--bs-border-color);border-radius:.5rem;"></div>
    <code class="d-block mt-2 small">--bs-body-bg</code>
  </div>
  <!-- repeat for each token -->
</div>

List the hex value beneath the variable name for clients who do not read CSS. A short JavaScript snippet can read getComputedStyle to output the computed value automatically, future-proofing the swatches against token changes.

2. Typography Scale

Render every heading level, body size, and utility class (.lead, .text-muted, .small, .display-1 through .display-6) with the actual text, the class name, and the computed font size. If you are using clamp() for fluid typography, note the minimum and maximum values. This matters especially when following the approach described in Fluid Typography in Bootstrap 5 with clamp() and CSS Variables, where the rendered size shifts across breakpoints and a static screenshot will mislead you.

3. Spacing Scale

Bootstrap 5’s spacing utilities run from .m-0 to .m-5 plus custom extensions. Display each step as a coloured bar whose width or height matches the actual computed pixel value. This gives designers an immediate spatial reference without opening DevTools.

4. UI Components

This is the core of any UI pattern library. For each component, show the live rendered version followed by a syntax-highlighted code block. The two-column layout below keeps them visually paired:

<section class="sg-component mb-6">
  <h3 class="sg-component-title">Primary Button</h3>
  <div class="sg-preview p-4 border rounded-top">
    <button type="button" class="btn btn-primary">Save Changes</button>
    <button type="button" class="btn btn-primary" disabled>Disabled</button>
  </div>
  <pre class="rounded-bottom m-0"><code class="language-html">
&lt;button type="button" class="btn btn-primary"&gt;Save Changes&lt;/button&gt;
  </code></pre>
</section>

Prioritise the components your project actually uses: buttons, form inputs, cards, alerts, badges, modals, and navigation. Document usage rules alongside each component. For example: “Use .btn-primary for a single primary action per viewport. Use .btn-outline-primary for secondary actions.”

5. Page-Level Patterns

Document full sections: hero layouts, feature grids, pricing rows, testimonial carousels. These are harder to render inline, so link to dedicated demo pages rather than embedding them. A simple anchor list at the top of the style guide page is sufficient.

Navigation and Discoverability Inside the Page

A style guide page grows long quickly. Use Bootstrap 5’s Scrollspy to keep a sticky sidebar in sync with the reader’s position. Each section heading gets an id attribute, and the sidebar anchors point to those ids. The result is a navigable document that behaves like official documentation.

<body data-bs-spy="scroll" data-bs-target="#sg-nav" data-bs-offset="80">
  <nav id="sg-nav" class="position-sticky top-0 p-3" style="width:220px">
    <ul class="nav flex-column">
      <li class="nav-item"><a class="nav-link" href="#colours">Colours</a></li>
      <li class="nav-item"><a class="nav-link" href="#typography">Typography</a></li>
      <li class="nav-item"><a class="nav-link" href="#spacing">Spacing</a></li>
      <li class="nav-item"><a class="nav-link" href="#components">Components</a></li>
      <li class="nav-item"><a class="nav-link" href="#patterns">Patterns</a></li>
    </ul>
  </nav>
  <main class="flex-grow-1 p-4">
    <!-- sections here -->
  </main>
</body>

The full implementation details for Scrollspy, including offset calculations for sticky headers, are covered in Bootstrap 5 Scrollspy for Long One-Page Sites.

Keeping the Style Guide Alive Over Time

The most common reason style guides go stale is that updating them requires a separate manual step. Eliminate that step wherever possible.

• Single source of truth for tokens. Define colours, spacing, and font sizes once in Sass variables or CSS custom properties. Both the production stylesheet and the style guide page read from the same source, so the swatches update automatically on rebuild.
• Add a style guide entry as part of the definition of done. When a new component is merged, the pull request is not complete until the style guide entry exists. This is a process rule, not a technical one, but it is the most effective safeguard.
• Version the page, not the components. Add a small “Last updated” timestamp to the page header, populated by your build tool. This gives clients and collaborators confidence that what they are reading reflects the current build.
• Exclude from production deployments. Add styleguide/ to your .gitignore deployment filter or your hosting platform’s exclude list. The page is a development and handoff tool, not a public-facing page.

Looking for a production-ready Bootstrap 5 HTML template? Browse Canvas Template demos and find the perfect starting point for your next project.

If you’re building with the Canvas HTML Template and want to ship production-ready Bootstrap 5 layouts faster, try Canvas Builder free — the visual builder that exports clean Canvas-ready markup in minutes.