/* Happy Pet Connect — site.css
*
* THE single CSS file for this platform (3.12.0 — rebuilt from scratch after
* the old tokens.css/site.css/admin.css/timegrid.css/theme.css split proved
* too easy to get out of sync with itself). Loaded on EVERY site page —
* this component's own views AND everywhere else (Cassiopeia chrome,
* Joomla's own profile page, articles, other extensions) — by
* plg_system_hpctheme, a system plugin that fires regardless of which
* extension is active. There is no template-level copy of this file: it's
* one physical file, in this component's own media/ folder, linked directly
* by path from the system plugin. Also registered normally (WebAssetManager)
* by this component's own site views — same file either way, never a second
* copy to drift out of sync.
*
* SCOPE, DELIBERATELY, FOR NOW: brand-colour hook (so BrandingHelper's
* per-instance colour keeps working) + a real, elegant dark mode covering
* Bootstrap/Cassiopeia site-wide. Component-specific look (cards, badges,
* the booking calendar, rewards widgets...) is NOT rebuilt yet — those
* render with stock Bootstrap styling until asked for.
*
* DARK MODE ACTIVATION: driven by `data-bs-theme="dark"` on , set by
* plg_system_hpctheme — either an explicit pet-parent choice, or (the
* default, for guests and anyone who's never touched the toggle) resolved
* client-side from the device's own prefers-color-scheme signal, so the
* WHOLE site follows the visitor's browser/OS automatically with no manual
* step (see HpcTheme::themeScript(); restored in 3.15.1 after a brief
* "light always" detour in 3.14.5). Every dark rule below is scoped under
* that one attribute — nothing here reacts to anything else.
*/
:root {
/* "light dark" tells the browser this page supports both and to use the
user's own preference for anything not explicitly covered by the
data-bs-theme rules below (native scrollbars, form-control chrome,
etc.) — consistent with plg_system_hpctheme resolving the SAME
device signal for data-bs-theme itself, so there's no brief mismatch
between UA-styled bits and this file's own dark rules. */
color-scheme: light dark;
/* Brand colour — BrandingHelper (Options → Branding) overrides this per
instance via an inline :root block it emits on every page load. Falls
back to the template's own --bs-primary, then a fixed default, so an
unbranded instance still looks intentional. */
--hpc-primary: var(--bs-primary, #1f3c88);
--hpc-primary-contrast: #fff;
/* Hover/selection wash, derived from --hpc-primary via color-mix() against
--hpc-surface/transparent rather than a precomputed literal — so the
same declaration already reads correctly once --hpc-surface flips dark
below, with no separate override needed. BrandingHelper mirrors this
exact formula for a per-instance brand_primary override. */
--hpc-primary-tint: color-mix(in srgb, var(--hpc-primary) 8%, var(--hpc-surface));
--hpc-primary-ring: color-mix(in srgb, var(--hpc-primary) 16%, transparent);
/* Selected-slot pill (booking calendar) — deliberately distinct from
--hpc-primary so a chosen time reads unmistakably "picked" against
the primary-coloured chrome around it (nav buttons, Add to cart),
rather than blending into "just another primary-coloured thing".
Same value in both themes — chosen for contrast against both. */
--hpc-slot-selected: #bd4c9b;
/* Status/semantic — overridable via brand_danger (Options → Branding). */
--hpc-danger: var(--bs-danger, #dc3545);
--hpc-muted: var(--bs-secondary-color, #64748b);
/* Surfaces & lines the booking calendar (Month grid + timegrid.css's
Week view) is built on — overridable via brand_surface/brand_border
(Options → Branding). */
/* 3.35: softened off pure white — glare complaint on the live site.
--hpc-surface now a neutral light grey instead of #fff (earlier warm/
cream attempts read as "yellow" once tiled across the Month grid's
30+ day cells — .hcc-book-day in booking.css — even though the same
tint looked fine on a single card), sunken/border darkened to match
so the tiered-elevation contrast relationships (surface floats above
sunken, border still reads against both) stay intact. Chosen
interactively against the actual booking UI, not picked blind. */
--hpc-surface: #f2f2f2;
--hpc-surface-sunken: #d6d6d6;
--hpc-border: #dbdbdb;
--hpc-border-light: #e8e8e8;
/* Phantom token fix (THEME_AUDIT.md §0): var(--hpc-text) is used at 15+
call sites across this file but was never actually defined here — it
only exists under this name in the admin-only tokens.css, which site
pages don't load. Every one of those call sites was silently resolving
to whatever colour happened to be inherited from its ancestor instead
of a real token, which is why "make it theme-aware" fixes routed
through var(--hpc-text) kept visibly failing (confirmed live: header
business-name text stayed white in light mode after being pointed at
this token). Defining it for real here backs every existing call site
at once — none of them need to change. */
--hpc-text: #1e293b;
--hpc-text-faint: #94a3b8;
--hpc-text-soft: #475569;
--hpc-text-placeholder: #cbd5e1;
/* Component-level vars several Bootstrap parts read directly — the
light-mode counterpart to the same block dark mode retunes below.
Without this, .card/.modal/.dropdown/.list-group (e.g. .hpc-modal-
dialog's .card, which the slot-picker/rewards/cart modals all use)
fall back to Bootstrap's own hardcoded white/grey defaults and never
pick up the --hpc-surface softening above — confirmed live via
devtools on the slot-picker modal (.hpc-modal-dialog.card showed
Background: #FFFFFF while the rest of the page correctly softened). */
--bs-card-bg: var(--hpc-surface);
--bs-card-border-color: var(--hpc-border);
--bs-modal-bg: var(--hpc-surface);
--bs-modal-content-bg: var(--hpc-surface);
--bs-modal-content-border-color: var(--hpc-border);
--bs-modal-header-border-color: var(--hpc-border);
--bs-modal-footer-border-color: var(--hpc-border);
--bs-dropdown-bg: var(--hpc-surface);
--bs-dropdown-border-color: var(--hpc-border);
--bs-list-group-bg: var(--hpc-surface);
--bs-list-group-border-color: var(--hpc-border);
/* Elevation — a tight contact shadow + a soft diffuse one, so a lifted
calendar event/card reads as an actual object rising off the page. */
--hpc-shadow-resting: 0 1px 2px rgba(15, 23, 42, .06), 0 1px 1px rgba(15, 23, 42, .04);
--hpc-shadow-lifted: 0 20px 30px -14px rgba(15, 23, 42, .35), 0 8px 12px -6px rgba(15, 23, 42, .14);
--hpc-radius: 10px;
--hpc-radius-sm: 6px;
--hpc-radius-lg: 18px;
/* Accent — second gradient stop alongside --hpc-primary, overridable per
instance via brand_accent (Options → Branding; BrandingHelper already
read this token before it had a default here). Used for the dark-mode
gradient/glow identity (see --hpc-gradient-primary/--hpc-glow-shadow
below) — light mode never applies a gradient, so this only surfaces
once data-bs-theme="dark" overrides it further down. */
--hpc-accent: #14b8a6;
--hpc-gradient-primary: linear-gradient(135deg, var(--hpc-primary), var(--hpc-accent));
/* Soft-shadow surface pair (3.26 "neomorphic-hybrid" redesign) — a light
shadow + a dark shadow on opposite corners, both colour-mixed FROM
--hpc-surface itself (never a flat literal) so a per-instance
brand_surface override still drives the right tone automatically.
Deliberately used ONLY on passive/structural surfaces (cards, panels,
inputs at rest) — never on .btn-primary/.btn-danger, which keep a
solid fill + real contrast so actionable buttons stay unambiguous.
Dark mode does not get an --hpc-neo-shadow-* pair at all: on a near-
black surface a light/dark dual shadow reads as noise, not depth — the
dark side's equivalent "soft" identity is --hpc-glow-shadow instead. */
--hpc-neo-shadow-out: 6px 6px 14px color-mix(in srgb, var(--hpc-surface) 80%, #000 20%),
-6px -6px 14px color-mix(in srgb, var(--hpc-surface) 96%, #fff 4%);
--hpc-neo-shadow-in: inset 3px 3px 8px color-mix(in srgb, var(--hpc-surface) 82%, #000 18%),
inset -3px -3px 8px color-mix(in srgb, var(--hpc-surface) 97%, #fff 3%);
/* The card system's base elevation, indirected through one token so a
SPECIFIC card (e.g. a star-tier pet card, see .hpc-star-glow) can add
its own extra shadow layer on top without fighting the generic card
rule's specificity for control of the box-shadow property — both
reference this same variable instead of each hard-coding the raw
shadow value. */
--hpc-card-shadow: var(--hpc-neo-shadow-out);
/* Rewards medal colours (referenced by templates since v3.3.0, never
actually defined after the v3.12.0 CSS rebuild — confirmed missing by
grep, 3.15.1). Literal, deliberately NOT brand-overridable — a medal
colour means something specific regardless of a Business's own brand
hue, same precedent as the booking-status cues elsewhere. Same values
in both themes on purpose: a gold star should read as gold whether the
page around it is light or dark. */
--hpc-star-bronze: #b0764a;
--hpc-star-silver: #9aa4b2;
--hpc-star-gold: #d4a72c;
/* Notification badge (cart count, PWA bottom-bar indicators) — fixed
high-contrast red, deliberately NOT tied to --hpc-primary. The old
badge used bg-primary, which matched the button it sat on (and could
match --hpc-primary-derived surfaces like the mobile bar's centre
icon) and lost all affordance as an "action needed" signal. #dc2626
on white passes WCAG AA (4.5:1+) and is left un-themed like the medal
colours above — a notification badge should read the same regardless
of light/dark. */
--hpc-badge-notify-bg: #dc2626;
--hpc-badge-notify-fg: #fff;
}
/* ======================================================================
Scrollbar visually hidden, scrolling still works (3.25.8x) — third attempt
at this exact problem. History: negative-margin overlay trick (3.25.71) ->
scrollbar-gutter: stable (3.25.80, reintroduced a permanent blank gutter
on every non-scrolling page, the same bug that got `stable` dropped the
FIRST time round at 3.23.28) -> this. Scrolling itself is untouched (wheel/
touch/keyboard/trackpad all still work); only the visible track/thumb and
any reserved gutter space are removed, on both the root scroller and any
internal `overflow:auto` panel. Deliberate tradeoff, explicitly requested:
desktop mouse users lose the scroll affordance and can't drag a thumb.
Do not silently swap this for scrollbar-gutter or the negative-margin
trick again without a fresh discussion — this exact spot has flip-flopped
three times already. */
* {
scrollbar-width: none; /* Firefox */
-ms-overflow-style: none; /* legacy Edge/IE */
}
*::-webkit-scrollbar {
display: none; /* Chrome/Safari/Edge — covers html's own scrollbar too,
unlike the old dark-mode rule this file already got bitten by (see the
::-webkit-scrollbar block further down): a bare `*` universal selector
has no descendant-combinator gap, so it matches itself. */
width: 0;
height: 0;
}
/* ======================================================================
Light-mode elevation (3.15.1) — the missing half of the "tiered surfaces"
idea dark mode already has (body recedes, cards visibly float above it,
see the dark palette block below). Light mode never got its own version
of that: body sat at pure white, identical to every card on it, so
nothing ever visually lifted off the page — one root cause of the "dog's
breakfast" read on My Rewards/My Pets, on top of the missing component
CSS fixed further down. --hpc-surface-sunken already existed as a token
(used by the booking calendar) but nothing ever applied it to body
itself. Dark mode's own body rule (below) uses !important and wins
regardless of source order, so this is safe to state unconditionally.
====================================================================== */
body {
background-color: var(--hpc-surface-sunken);
}
/* ======================================================================
Paw-print background (3.16.2, broadened to every page in 3.19.1 — was
inconsistently scoped to `body.hpc-home` only, so most of the site still
sat on the plain --hpc-surface-sunken fill while the Home page alone got
the pattern; now every page gets it, standardising the look site-wide).
`body.hpc-home` (see HpcTheme::isHomePage()/applyHomeBackgroundClass() —
"Home" means Joomla's own default Main Menu item) still exists and still
drives the SEPARATE Home-page article polish further down this file
(the hero-photo/card treatment) — only the background itself moved off
that class onto plain `body`. No image asset exists for this, so the pattern is a small
inline SVG tile (three paws at varied size/rotation so the repeat doesn't
read as a rigid grid) — no request, no file to ship. Each paw is drawn
THREE times at the same spot, offset by 1px: a dark copy, a light copy,
then a faint base fill — that's what gives the "embossed/pressed into the
surface" look rather than a flat printed paw, done inside the SVG itself
so no CSS filter (which would also blur real content) is needed. Two full
tiles, not one recoloured via currentColor — a background-image data URI
is loaded as an external image context, so `fill="currentColor"` inside
it does NOT reliably inherit the page's `color` in every engine; explicit
colours per theme is the safe choice already used elsewhere in this file.
Never verified in a real browser (see this file's own header + CLAUDE.md's
FullCalendar history for why that's an honest, standing limitation of this
dev sandbox) — low-opacity and additive-only (background-image on top of
the existing background-color), so a rendering surprise here is cosmetic,
never a layout break. */
body {
/* Light mode never overrode the template's own --body-bg (#fff,
big_goose/media/css/template.css:80) — pure white plus a ~5%-opacity
paw print reads as harsh, especially next to dark UI chrome (header,
banners). Dark mode already repaints this to --bs-body-bg; give light
mode the same "sunken page, raised card" treatment every card on the
platform already assumes (cards sit on --hpc-surface #fff) instead of
leaving the page itself flat white. */
background-color: var(--hpc-surface-sunken);
background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='170' height='170' viewBox='0 0 170 170'%3E%3Cdefs%3E%3Cg id='p'%3E%3Cellipse cx='0' cy='14' rx='13' ry='10'/%3E%3Ccircle cx='-12' cy='-4' r='5.2'/%3E%3Ccircle cx='-4' cy='-11' r='5.6'/%3E%3Ccircle cx='5' cy='-11' r='5.6'/%3E%3Ccircle cx='13' cy='-4' r='5.2'/%3E%3C/g%3E%3C/defs%3E%3Cg transform='translate(36,40) rotate(-18) scale(0.9)'%3E%3Cuse href='%23p' x='1' y='1' fill='%23000000' fill-opacity='0.05'/%3E%3Cuse href='%23p' x='-1' y='-1' fill='%23ffffff' fill-opacity='0.6'/%3E%3Cuse href='%23p' fill='%23000000' fill-opacity='0.025'/%3E%3C/g%3E%3Cg transform='translate(126,100) rotate(15) scale(1.05)'%3E%3Cuse href='%23p' x='1' y='1' fill='%23000000' fill-opacity='0.05'/%3E%3Cuse href='%23p' x='-1' y='-1' fill='%23ffffff' fill-opacity='0.6'/%3E%3Cuse href='%23p' fill='%23000000' fill-opacity='0.025'/%3E%3C/g%3E%3Cg transform='translate(74,140) rotate(-6) scale(0.78)'%3E%3Cuse href='%23p' x='1' y='1' fill='%23000000' fill-opacity='0.045'/%3E%3Cuse href='%23p' x='-1' y='-1' fill='%23ffffff' fill-opacity='0.55'/%3E%3Cuse href='%23p' fill='%23000000' fill-opacity='0.02'/%3E%3C/g%3E%3C/svg%3E");
background-repeat: repeat;
background-size: 170px 170px;
background-attachment: fixed;
}
/* ======================================================================
Home page article polish (3.16.3) — reported directly from a live
screenshot: the Home page's own content (a raw, full-column-width
uploaded photo + plain WYSIWYG paragraphs) renders as bare, unstyled
Joomla core article markup — no different from any other article on the
site, and now visibly at odds with the paw-print treatment just given the
page around it. Scoped under `body.hpc-home` (see above) plus Joomla
core's OWN guaranteed article wrapper class, `.item-page` — present in
com_content's article view across every recent Joomla version, so this
doesn't depend on knowing this Business's actual article HTML in advance.
Same "best-effort, inert if the live markup doesn't match" caveat as
every other Cassiopeia-chrome selector in this file (see this file's own
header — no real browser here to verify against) — only the Home page is
touched, nothing else on the site.
Four moves, all reversible/inert independently if one doesn't match:
1. The whole article sits on its own card surface (--hpc-surface, same
language as every card elsewhere on this platform), so it visibly
lifts off the paw-print background instead of floating bare on it —
"tiered surfaces" carried through to this page too.
2. Cassiopeia's own page-header title ("Home") is shrunk to a small
uppercase kicker rather than hidden outright — the article's OWN
heading ("Welcome to ...") already says more, so a second full-size
title directly above it was pure repetition, but removing the
heading entirely would lose the admin's inline "Edit" affordance
Cassiopeia attaches to it.
3. The hero photo — the actual ask ("make the image smaller") — goes
from its raw uploaded size to a fixed, cropped banner height,
rounded and lifted with a shadow, so it reads as a designed hero
strip instead of a raw photo dropped into the page.
4. Body copy gets a capped line length (readability) and real vertical
rhythm between headings/paragraphs instead of the WYSIWYG default's
cramped spacing. The "What We Offer" list specifically — each
service is a bold emoji-led label followed by its own paragraph —
gets a quiet left-rail treatment via `:has(> strong:first-child)`,
styling paragraphs by their actual existing shape rather than
requiring the article content itself to be restructured with new
classes (which a Business's own content editor doesn't control).
====================================================================== */
body.hpc-home .item-page {
max-width: 900px;
margin-inline: auto;
background: var(--hpc-surface);
border: 1px solid var(--hpc-border);
border-radius: 16px;
padding: 1.75rem clamp(1rem, 4vw, 2.5rem) 2.25rem;
box-shadow: var(--hpc-shadow-resting);
/* Contains the hero image's float below (see that rule's own comment) so
the card's own background/padding always wraps the full article
height, never collapsing around a floated child the way a plain block
formatting context would — a modern, non-clipping alternative to the
classic "overflow: hidden" clearfix (which would risk cutting off the
image's own box-shadow). Live-screenshot-confirmed bug (3.16.3 first
pass): without this, the card visibly failed to wrap the article at
all — its box shrank to just the text beside the still-floated image. */
display: flow-root;
}
body.hpc-home .item-page .page-header {
border: 0;
margin-bottom: .25rem;
padding-bottom: 0;
}
body.hpc-home .item-page .page-header h1 {
font-size: .78rem;
text-transform: uppercase;
letter-spacing: .08em;
font-weight: 600;
color: var(--hpc-muted);
margin: 0;
}
/* Two-layer float fix (3.16.5 — the 3.16.4 attempt targeted only the
itself and a second live screenshot, taken AFTER that version genuinely
reached the site this time, showed the exact same wrap persisting: the
image's own rounded corners/shadow (only ever declared on the tag)
rendered correctly, proving this selector DOES match — but the image
stayed narrow and text still wrapped beside it, which only makes sense if
`float`/an explicit width live on the element WRAPPING the image (Joomla's
WYSIWYG typically inserts a bare image inside its own `