This is a summary of the steps taken to create modern site from scratch, loosely in-the-style-of, but pretty much from scratch, building a proper CSS system, and wiring it into a fresh Textpattern install.

---

Step 1 — Honestly assess what you’re starting from

Before designing anything, check what actually exists. A page can look styled in memory or an old screenshot while the live version has regressed to bare, unstyled HTML — plain black text, default browser fonts, no colors beyond default link blue, no layout. If that’s the case:

• There’s no existing CSS to extract or “overhaul” — you’re starting from zero, not refactoring
• An old screenshot (if you have one) becomes your only reference for colors/structure, not the live markup — the original source HTML/CSS may simply no longer exist anywhere accessible
• Decide explicitly: are you reviving the old look, or using its bones (palette, structure) as a launchpad for something new?

Step 2 — Define a design token system before writing any CSS

Don’t jump straight to styling elements one by one. Fix a small set of values first, so every component draws from the same system:

• Color tokens — e.g. a primary brand color, a dark neutral for nav/footer/text, a very light tint for backgrounds, white for cards, and a near-black ink for body text (5 colors is usually enough for a small site)
• Type tokens — one typeface for headings (can have more character/personality), one for body and navigation (should stay highly legible)

Keeping the old palette but flattening the execution — removing gradients, bevels, and drop shadows in favor of flat color and real typography — is a reliable way to modernize a design without losing its identity.

Step 3 — Build a static HTML + CSS preview first

Build two files before touching Textpattern at all:

• @preview.html@ — a full working demo you can open directly in a browser to check fonts, hover states, and any animation/interaction
• @style.css@ — the same CSS pulled out standalone, ready to be pasted into Textpattern later

Working this way means you can review and adjust the design entirely outside the CMS — faster to iterate on, and you’re not fighting template caching or admin-panel previews while still deciding on the look.

Design system hygiene worth building in from the start:

• Mobile-first, with clear breakpoints (e.g. 2-column → 1-column)
• Visible focus states for keyboard navigation
• Respect prefers-reduced-motion for any animation
• Keep custom SVG marks/logos as separate standalone asset files, not just inlined once — useful later for favicons, email signatures, etc.

Step 4 — Check browser support before committing

Once the design is using modern CSS (custom properties, Grid, clamp(), :focus-visible, gap in flexbox), check what you’re trading off:

Feature	Typical support
CSS custom properties (:root variables)	All modern browsers. Not IE11.
Flexbox	Universal, IE11 mostly fine with quirks
CSS Grid	All modern browsers. IE11 only partial/prefixed
gap in flexbox	All modern browsers since ~2021
clamp() for responsive type	All modern browsers since 2020
:focus-visible	All modern browsers since ~2021

For a small business site today, targeting current Chrome/Firefox/Safari/Edge and not spending effort on IE11 (long dead, unsupported by Microsoft since 2022) is the reasonable default — unless your own analytics say otherwise.

Step 5 — Map the static markup onto Textpattern’s structure

This is the key translation step — going from plain HTML to Textpattern’s tag system:

• Navigation → replace hard-coded <ul> nav items with <txp:section_list wraptag="ul" />, or your existing nav form if you already have one
• Repeating content blocks (e.g. service cards) → good candidates for <txp:article_custom> if each one is a real article; otherwise hard-code them directly in a Form if they’re static and won’t change often
• Footer (copyright, links) → your existing footer Form, just re-classed to match the new CSS

Step 6 — Wire the CSS and fonts into Textpattern

1. CSS: go to Presentation → Styles, paste your style.css into the active style (or create a new one, e.g. modern), then set it as the site’s default under Presentation → Sections
2. Web fonts: add the font <link> tags from the top of your preview.html into your Page template’s <head> area, or a shared <txp:output_form form="head" /> include if you’re using one
3. Keep any large or reusable CSS components (e.g. a timeline block) in their own separate CSS file, linked via <link rel="stylesheet"> rather than inlined — a clean drop-in for Textpattern’s Styles panel, and easier to maintain independently of the main stylesheet

Step 7 — Handle special pages properly (don’t skip the 404)

A stock Textpattern install ships with two demo-ish pairings worth telling apart:

• @archive@ section/page — this is just a demo pairing showing that a section can use a different page template. It has no real functionality (no automatic date-based archive listing) — safe to delete if unused. Before deleting: check Presentation → Sections for any articles assigned to it and reassign them first, then delete the section, then delete the now-unused page template.
• @error_default@ section/page — this is not the same kind of thing. It’s what Textpattern actually renders when a request fails to resolve (bad URL, deleted article, typo). Keep it, and style it properly:
  • Reuse your site’s shared header/nav/footer so a 404 doesn’t feel like a dead end
  • Reuse existing components (e.g. a “notice box” style) rather than inventing new classes just for the error page
  • Double-check the section is correctly flagged to serve a real HTTP 404 status, not just a 200 page that happens to say “not found” — this matters for SEO and crawlers
  • Swap any hardcoded links (href="/") for <txp:site_url /> or <txp:section /> so they resolve correctly wherever the site is installed

Step 8 — Don’t forget default text formatting

If your site’s body-text formatter uses Textile shorthand (Textpattern’s default), check that block code formatting (bc., which renders as <pre><code>) actually has CSS applied — it’s easy to build a whole design system and forget pre/@code@ entirely, leaving it to fall back to small, unstyled, awkward-looking browser defaults. Worth fixing proactively, especially if any part of the site is likely to show code or markup samples.

---

Optional — A CSS Zen Garden-style theme switcher

If you want to preserve an old design alongside a new one (rather than just replacing it), the CSS Zen Garden model works well: one shared HTML structure, multiple stylesheets, and a small script that swaps which stylesheet is active via a <link id="theme-stylesheet"> element.

The catch: true 1:1 Zen Garden reuse needs the original source markup — if the live old design no longer exists as real code (only as a screenshot or memory), you can’t literally swap stylesheets onto identical original HTML. The workaround is to rebuild the old look as a second stylesheet (e.g. legacy.css) applied to your new shared markup/classes, hiding any newer elements that have no equivalent in the old design via CSS rather than needing separate markup for each skin.