Victor Orlando — Style Sheet & Technical Standards

Victor Orlando Site — Style Sheet & Technical Standards

For Ryan (and anyone else building for this site). These are confirmed, standing rules — not preferences to weigh case by case. Apply them by default; deviations need Cara's explicit sign-off.

1. Color Tokens

Use these exact values. Don't introduce new colors without checking here first.

Token	Hex	Use
`--bg`	`#000000`	Base background, every section
`--gold-1`	`#b8823d`	Secondary gold
`--gold-2`	`#e2a64a`	Primary gold — links, borders, icons, active states
`--gold-text`	`#dcb46a`	Eyebrows / labels on dark background
`--focus`	`#f0c869`	Focus ring color, all interactive elements
Legal/fine print	`#a89a7c`	Verified AAA (7.58:1) on black — footer copyright/legal row only
CTA button gradient	`#f0c869 → #dca83e → #c9952a` (135deg)	Primary buttons
CTA button text	`#0a0804`	Verified AAA (7.45:1) against the darkest point of the gradient — do not use `#1a1206`, it only clears AA (6.9:1)

Backgrounds must stay dark everywhere. No gradient or transition from dark to white/near-white, anywhere on the site.

Background
#000000

Gold primary
#e2a64a

Gold secondary
#b8823d

Gold text
#dcb46a

Focus ring
#f0c869

Legal text
#a89a7c

2. Typography

Font stack: system fonts only. No Google Fonts, no "Inter" reference anywhere (including as a fallback name). css font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Helvetica, Arial, sans-serif;
Units: px only. Never pt. (pt has shown up repeatedly in submitted code — convert on sight.)
16px minimum, everywhere, with one exception: copyright/legal fine print in a footer may go smaller (e.g. 13px) since it shouldn't visually compete with real content at that size. Nothing else is exempt — not labels, not buttons, not tooltips, not tour/show metadata.

3. Technical Standards (non-negotiable, catches real bugs)

Every section's outermost wrapper needs its own explicit background color. Never rely on <body> alone — these files get pasted as fragments into Divi Code Modules with no real <body> tag, so a body-only background falls through to white in production even when a standalone file preview looks correct.
List-style reset must be explicit on ul, li, AND li::marker — resetting only the ul isn't enough; Divi's default list styles can bleed through with higher specificity and produce stray bullet dots even when a custom separator is (or isn't) in use.
Images: real hosted URLs only in delivered/production files — no base64 embeds (bloats file size, breaks browser caching). loading="eager" for anything above the fold (logos, hero images); loading="lazy" for anything below the fold. Always set explicit width/height attributes to prevent layout shift.
Never fabricate a src URL. If no confirmed asset exists, leave it empty/placeholder and say so — don't guess a plausible-looking path.
Divi override risk: if a style isn't rendering as coded, check whether Divi's theme CSS has higher specificity — fix with !important on the specific property, don't rewrite the component.
Touch targets: 44×44px minimum on every interactive element (buttons, icon links, toggles).
Focus states: every interactive element needs a visible :focus-visible outline (2px solid var(--focus), offset 3px) — no exceptions, including icon-only buttons.
Contrast policy: AAA (7:1) is the governing target for all text. AA (4.5:1) is only acceptable as a documented, explicitly-approved exception — never a default fallback. See §14 for the approval process and the one currently approved exception (Phoenix Caliente red).

4. Icons & Tooltips

Icon-only elements that aren't universally recognizable (social platform icons, etc.) get a hover/focus tooltip showing the label — CSS-based, not the native title attribute (too slow, inconsistent). Keyboard-focus-accessible, not hover-only.
Universally recognized icons (e.g. a mail/envelope icon) don't need a tooltip.
Every icon-only button/link still needs a real aria-label regardless of whether it also has a visual tooltip.

5. Content Rules

No fabricated facts, ever — no invented tour dates, bios, quotes, or venues. If something isn't confirmed, mark it TBA or leave it out; don't fill the gap with something plausible-sounding.
No ticket sales anywhere on the site. No "Tickets" links, no purchase flow — this is a standing decision, not a per-section judgment call.
"Shows," not "Tour." Victor's dates are individual gigs at varied venues, not a traditional multi-city tour circuit. Applies to nav label, page URL (/shows/), and any related copy.

6. Accessibility Rules

Text over a photograph can never be certified as meeting contrast requirements — even with a gradient/scrim overlay, actual contrast varies pixel-to-pixel with the image underneath. A computed ratio against a theoretical worst-case color (e.g. pure black) is not proof of the real rendered contrast. Any text over a photo needs a solid, fully opaque backdrop panel behind it — not a partial-opacity gradient — so the real background color is provable, not estimated.
Reference/data text is never styled in a decorative accent color. Hex codes, labels, and key terms in a style guide or any info-first document use plain near-black (or near-white on dark) only — the same "no grey or light/faint text" principle that governs body copy elsewhere. Accent colors (gold, etc.) are reserved for structural elements — section headers, table headers — never for the data itself.
Active/current-page nav highlighting must be dynamic, never hardcoded. The same nav file is reused across every page on the site, so hardcoding aria-current="page" onto one link (e.g. "Home") makes that link show as active on every page, not just its own. Fix: a small script comparing window.location.pathname against each link's href on load, setting aria-current="page" only on the actual match and clearing it from every other link.

7. Content Sign-Off Rules

Never add a factual or status claim about Cara's client or their work without her explicit permission first — even when the claim is true and already on record elsewhere (e.g. "Now Submitted for Grammy Consideration"). Publishing it to a live page is a content decision that needs her sign-off, not something to insert unilaterally while building a component.

8. Credit Line Sizing (exception, confirmed by Cara)

Design/artwork/player credit lines (e.g. "Design by Cara Harpole," "Artwork by Cara Harpole," "Player design by Cara Harpole") may go smaller than the 16px floor — same category of exception as footer copyright/legal fine print. A credit line shouldn't visually compete with real content at full body size.

9. Body Copy Color

Body copy on dark backgrounds uses a light cream tone, not pure white — e.g. #f4eee4 (verified 17.66:1 against #050505, well past AAA). Pure white reads harsher against the warm dark palette than a soft cream does; a muted secondary tone (#c7bfb3, verified 11.19:1) is used for supporting/metadata text (artist credits, timestamps).

10. Audio Player Component Standards

Play/pause button: circular, gold outline, transparent fill, 46px (44px minimum maintained at every breakpoint). Icon swaps between play/pause via CSS class toggle, not a re-render.
Waveform: rendered as individual bars (<span class="vo-bar">), each with a data-base height attribute holding its resting value. Played portion is indicated with a gradient fill (gold → orange → red) via a .is-played class toggled per-bar based on playback percentage — not a single overlay bar, so the waveform shape itself stays visible under the progress indicator.
Seeking: the waveform container is a real role="slider" with aria-valuemin, aria-valuemax, aria-valuenow, and a live aria-valuetext (e.g. "1:24 of 3:40") — not just a visual scrubber. Click-to-seek and full keyboard support (Arrow keys ±5s, Home to start, End to end) both required.
Responsive seek control: if desktop and mobile use separate waveform elements, the waveform visible at each breakpoint must itself remain an accessible seek control. Never hide the visible mobile waveform from assistive technology while the functional desktop slider is hidden by CSS.
Settings panel (waveform motion toggle): a real disclosure pattern — aria-expanded on the trigger button, hidden attribute on the panel, closes on Escape and on outside click, returns focus to the trigger on close.
Bar overflow: waveform bars use justify-content: space-between on their container, never left flex: 1 alone to fill space — fixed-width bars with no explicit distribution rule leave a dead gap on wider screens.

11. Responsive Player Placement

Desktop (901px and wider): the custom audio player belongs in the right-hand song-information column, grouped with the song title, artist, and project/subtitle information. It should be visible as part of the primary listening experience without requiring the user to scroll below the artwork/content presentation.
Tablet and mobile (900px and below): the layout stacks vertically and the player moves below the primary song content. Give the player the available content width so the waveform, elapsed/total time, settings control, and touch targets remain comfortable and usable.
Responsive placement is intentional. Do not force one visual order across every breakpoint. Desktop prioritizes immediate listening access beside the artwork; smaller screens prioritize a clear stacked reading and interaction flow.
The decorative rule/divider marks a transition between the song identity/listening experience and supporting descriptive content where appropriate. Its exact placement follows the approved page composition rather than an automatic global order.

12. Reduced Motion

The waveform's idle "breathing" animation must respect prefers-reduced-motion: reduce — when set, bar height transitions are disabled entirely (transition: none !important), not just slowed. Playback progress still updates the played/unplayed color state normally; only the decorative motion is suppressed.
A user-facing "Waveform motion" toggle (On/Off) is available in the player's settings panel regardless of system preference, and persists via localStorage — the system preference sets the default, not a locked state.

13. Song Page Rules

Breadcrumb (Home / Music / [Song Name]) sits above the main grid, confirming the page's place in the site hierarchy.
Cover artwork and song identity are co-primary visual elements. Artwork may be capped to preserve balance and prevent it from overwhelming the listening interface, but it should remain prominent and intentionally scaled at each breakpoint.
The design/artwork credit line sits directly under the cover image, centered — see §8 for its sizing exception.
Order after the player: rule → description → Share button. Share is a secondary, end-of-page action (not everyone shares), so it sits last, with the description as supporting context immediately before it — not stranded below a "final action" element.

14. Contrast Exception Policy

AAA (7:1) is the default target (see §3). An AA-only color (4.5–6.99:1) may be used only when:

It's required for a specific brand/identity reason (not general body copy), and
It's explicitly approved by Cara, and
It's logged here with its actual verified number — not assumed compliant.

Approved exceptions:

Color	Use	Verified contrast	Approved for
`#d1493f`	Project/album name text (italic, on `#050505`)	4.6:1 (AA)	Song page project name only — not for body copy or any other element

Scope note: This document governs durable visual, accessibility, content, and technical standards. Page-specific zone numbers, temporary homepage sequencing, and other frequently changing content architecture are intentionally excluded so routine site changes do not make the style guide obsolete.

Keep this updated as durable standards change. When in doubt, check here before re-deriving a rule from scratch — several of these (the background bug, the list-style dots bug, the Inter/pt regression, the nav active-state bug) have had to be fixed more than once because they weren't written down anywhere until now.