Browser Tab Title Convention
Browser Tab Title Convention
Cross-site convention for <title> formatting and favicon presence across every
Woodfine/PointSav property. Ratified 2026-07-12 (command@claude-code, following a
proposal from project-marketing's mobile audit of home.woodfinegroup.com /
home.pointsav.com). Captured here because it is a real, reusable pattern any site in
the family can reference from one canonical source instead of re-deriving it — but it
is a naming convention, not a themed UI component, so it has no recipe.json/CSS
counterpart the way site-footer or attribution-badge do.
The rule
- Home page: brand token alone. No separator, no page word.
Example:
PointSav Software - Sub-page:
{Page Title} — {brand token}, using an em dash (—), not a pipe (|) or hyphen (-). Example:Products — PointSav Software - Brand token keeps the property descriptor, not a bare company name —
PointSav Design System,PointSav Software,PointSav Documentation, etc. With several family tabs open at once, a bare company name on every tab is undiscriminating. - Real SVG favicon (
<link rel="icon" type="image/svg+xml" href="...">) is part of the same standard on every page — do not assume it is already present; verify.
Drop-in template for any render_page()-equivalent head-builder:
title = page_title ? f"{page_title} — {brand_token}" : brand_token
Why an em dash, not a pipe
Sourced from real precedent (GitHub Docs, Stripe, Google Docs, Apple, Microsoft Learn) plus SEO data: Google rewrites pipe separators in search-result titles roughly 41% of the time, versus roughly 20% for dashes. A Semrush A/B test found dash-separated titles drove roughly 9% more organic clicks than pipe-separated ones. (Figures as relayed in the ratifying message — re-verify against the original sources before citing externally in a public-facing document; this file records the design decision and its rationale, it is not itself the primary source.)
Verification against this codebase
app-privategit-design's own render::shell() (templates/shell.html +
src/routes/browse.rs) already implements this pattern: sub-page titles render as
{label} — PointSav Design System (em dash, real token), the home page renders the
bare brand token (PointSav Design System), and a real SVG favicon
(/static/favicon.svg) is already wired on every page. No change was needed on
design.pointsav.com's own implementation when this convention was ratified — confirmed
by direct inspection, 2026-07-12.
Reference implementations
home.pointsav.com,software.pointsav.com— cited by the ratifying message as live reference implementations of this exact pattern.design.pointsav.com(app-privategit-design) — independently already compliant (see above).
Scope note
This is deliberately not a recipe.json component: it has no markup shape or CSS to
formalize, only a string-formatting rule and a favicon presence requirement. Sites
adopting it should implement the drop-in template directly in their own head-builder,
citing this file as the canonical source of the convention.
Canonical machine-readable formula (added 2026-07-12)
The exact separator/format rules above were independently formalized into a governed
token, tokens/linguistic/page-title-formula.yaml (project-editorial,
DESIGN-TOKEN-CHANGE-page-title-formula, master-cosigned 2026-07-12), following a
live audit of all 10 real running woodfinegroup.com/pointsav.com properties — 7 of 10
already matched this exact formula independently, 3 didn't (2 newsroom pages using a
pipe separator; gis.woodfinegroup.com's homepage carrying a tagline). This file remains
the rationale/citation record; the YAML token is the canonical, cross-archive-consumable
source of truth for the formula itself and the per-property site_display_names
registry — read that file, not this one, when implementing.
Important Information
Design System disclosure
This site provides open-source design tokens, documentation, and self-hostable software published by Woodfine Capital Projects Inc. Information here is for general reference only and does not constitute an offer, warranty, or a guarantee of fitness for any particular purpose. Statements regarding planned, intended, or targeted future features are forward-looking and subject to change without notice; they are not undertaken to be updated except as required by law.