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.