/* ============================================================================
IndianShopping guest-header accent — fallback override
----------------------------------------------------------------------------
For the shared HTML pages IS SERVES but does not own. Today that is one
page: /investors (SHARED_INVESTOR/frontend/investor.html, via
serve_investors), where backend/app/main.py injects this immediately
after the shared header's own stylesheet.
This is NOT the site carrier. static/css/indianshopping-brand-accent.css
defines --site-accent-fill, and on the 68 pages under frontend/ that is
exactly right. On investor.html it would be wrong, because two OTHER
consumers read the same hook and both treat a defined --site-accent-fill as
"this site has a brand of its own, stand down":
SHARED_INVESTOR/css/investor.css
--investor-accent: var(--site-accent-fill, #4f46e5)
SHARED_INVESTOR/js/investor-app.js::_applyBranding()
pins meta.accentColor ONLY when --site-accent-fill is empty
meta.accentColor is #ea580c — IS's own, from data/investor/investor-config.json
via frontend/js/investor-data.js. Linking the site carrier there would
therefore suppress IS's configured investor accent and repaint the portal in
#f97316. Measured in a browser, 2026-08-29: --investor-accent, -text and
-strong all move #ea580c -> #f97316, and white-on-accent contrast falls
3.56:1 -> 2.80:1, under the 3:1 WCAG floor for large text. Upstream's
precedence comment names that exact hazard ("measured as low as 2.82:1").
So this file overrides only what the header reads, and only in the position
header-embed.css left open — its own blue fallback:
header-embed.css --he-accent: var(--site-accent-fill, #3b82f6)
here --he-accent: var(--site-accent-fill, #f97316)
Two consequences follow, both wanted. It is inert wherever a real
--site-accent-fill exists, so it defers to the hub's generated
/auth/api/branding/theme.css if IS is ever opted in (that link sits later in
investor.html's and would otherwise be outranked by a flat value
here). And it changes NOTHING that renders today: the pinned bundle
(SHARED_DASHBOARD 3a7131a4, header-embed v2.2.0) already writes #f97316 onto
, and an inline style outranks this. From v2.2.3 that write is gone
and this is what keeps the header saffron.
Which of the bundle's two accent SOURCES does that write matters, because
only one of them reaches this page. _applyAccent() resolves a colour from a
source at two call sites: boot() calls _applyAccent(_resolveAccent()), which
keys the hardcoded SITE_ACCENTS table off window.DASHBOARD_SITE_CODE, and
_fetchSiteConfig() calls _applyAccent(_siteConfig.accent_color). (There is a
third call site, in _applyTheme(), but it is not a source: it re-applies the
already-resolved _accentHex to refresh the glow alpha on a theme toggle, and
is guarded by `if (_accentHex)`.) Measured on the served route,
DASHBOARD_SITE_CODE is the EMPTY STRING on investor.html, so _resolveAccent()
returns null and the boot() call no-ops. The write comes from /site.json's
accent_color. Both sources say #f97316, so the colour is the same either way
-- but do not "fix" this file by reasoning from the SITE_ACCENTS table, which
never fires here.
ORDER IS LOAD-BEARING, unlike in the site carrier. Both declarations target
:root at equal specificity, so this file only wins by coming later; the
injection anchors on the header-embed for that reason.
Values: #f97316 is site.json's accent_color and the colour the pinned bundle
renders. Glow alphas are the bundle's own, 0.2 dark / 0.1 light.
========================================================================= */
:root {
--he-accent: var(--site-accent-fill, #f97316);
--he-accent-glow: var(--site-accent-glow, rgba(249, 115, 22, 0.2));
}
:root[data-theme="light"] {
--he-accent-glow: var(--site-accent-glow, rgba(249, 115, 22, 0.1));
}