/*
 * Site-specific CSS customization for dev.fansconnect24.net.
 * This is Joomla's official "template.user" style hook (see
 * templates/cassiopeia/joomla.asset.json) - always loaded on every page,
 * intentionally shipped empty by Joomla core for exactly this purpose.
 *
 * FansConnect24 Design System 1.0 (Phase 3, Richtung C / Hybrid) is
 * loaded from here via @import, so the design system lives in its own
 * clearly organised files while staying inside this single, already-
 * approved Joomla customisation hook - no joomla.asset.json (a Joomla
 * core template file) was touched to register it. See
 * docs/DESIGN_SYSTEM_1.0.md for the full documentation.
 *
 * Cache-busting (added 2026-09-10 - Header/Hero/Slider fix): this file
 * itself (user.css) is a registered Joomla web asset and gets an
 * automatic version query from Joomla's WebAssetManager (the `?xxxxxx`
 * seen on its own <link> URL) whenever ITS content changes - but the
 * four @import targets below are each fetched by the BROWSER under
 * their own literal, un-queried URL, which Joomla's asset versioning
 * has no reach into. A browser that had already cached
 * fc-design-system/public.css (etc.) under that bare URL kept serving
 * the stale cached copy on every later visit, even after the file's
 * content and Last-Modified header changed on disk/server - confirmed
 * live: the served file and the file on disk were byte-identical
 * (verified via curl) while the SAME browser tab's own parsed CSSOM
 * (document.styleSheets) still reflected an older revision. Each
 * @import now carries its own `?v=` query - bump every one of these four
 * values (a shared date+letter suffix, incremented on any subsequent
 * fc-design-system/*.css edit is simplest) so every browser is forced
 * to treat it as a new URL and re-fetch, without touching any server/
 * production caching configuration.
 */

@import url("fc-design-system/tokens.css?v=20260921-portal-shell");
@import url("fc-design-system/base.css?v=20260917");
@import url("fc-design-system/public.css?v=20261021-ai-soon");
@import url("fc-design-system/creator-portal.css?v=20260922-apply-column-frame");

/* Cassiopeia's header markup wraps the site branding as
   <div class="navbar-brand"><a class="brand-logo">…</a></div>. The
   existing `.navbar-brand { text-decoration: none }` rule only targets
   the wrapping <div>, not the nested <a class="brand-logo"> - so the
   link falls back to Bootstrap's global `a { text-decoration: underline }`
   base rule. Scoped exclusively to this one branding link; does not
   affect any other link, the Creator navigation, or the menu toggle. */
.navbar-brand .brand-logo,
.navbar-brand .brand-logo:hover,
.navbar-brand .brand-logo:focus,
.navbar-brand .brand-logo:active {
    text-decoration: none;
}

/* Cassiopeia 6.1.3's core mod_menu submenu toggle is click/tap-only
   (media/mod_menu/js/menu.js sets aria-hidden via a click handler, no
   :hover anywhere in core). Desktop mouse users expect a header dropdown
   to also open on hover. This only adds a visual `display: block` on
   top-level `.parent` hover - it never touches `aria-hidden` or
   `aria-expanded`, so keyboard/click/screen-reader behaviour (core JS)
   is untouched. Scoped to `(hover: hover) and (pointer: fine)` so
   touchscreens (which report hover:none) never get a phantom hover
   state.
   Width threshold: since 2026-10-10 the header nav breakpoint FC24_NAV_BP
   = 1360px (Public Header Responsive Overflow Fix 1.0, see public.css);
   below it the menu sits in the hamburger panel. Originally 992px,
   matching Cassiopeia's original breakpoint
   (.mod-menu .parent > ul is only absolutely positioned there, see
   _header.scss `media-breakpoint-up(lg)`) - the 2026-09-09 "Header
   responsive nav" hamburger added in fc-design-system/public.css
   deliberately reuses this same 992px rather than a new one (see the
   comment there), so this rule still lines up: below 992px the menu is
   now inside the collapsed hamburger panel, where a hover-flyout would
   be wrong anyway. Keep both in sync if that value ever changes. */
@media (hover: hover) and (pointer: fine) and (min-width: 1360px) {
    .container-header .mod-menu > li.parent:hover > ul.mod-menu__sub {
        display: block;
    }

    /* Defensive hover-hit-area fix, 2026-09-09. li.parent's own
       hoverable box is only as wide as its short link text (~76px for
       "Creator"), while .mod-menu__sub below it is much wider (core's
       min-width:12rem) - moving the mouse toward an item on the right
       side of the open panel can cross the row boundary in the
       triangular gap to the right of the link but above the panel,
       which is outside both boxes and would end li:hover early. This
       invisible ::before bridges exactly that corner (core already
       uses li:after for the active-underline decoration, so ::before
       is free) - it does not change how the panel itself looks, only
       extends li.parent's real hit-area to match the panel's width
       immediately below the link. Does not touch display/aria-hidden/
       aria-expanded or any core JS.
       Note: with a real, logged-in Creator session, hover-opening and
       the click/toggle were both confirmed live and working; moving
       into the open panel via this session's browser-automation tool
       reproducibly closed it even after this fix, but the same tool
       could not keep :hover active across two separate synthetic
       mouse-move calls even along a short, gap-free path either - so
       that specific finding could not be attributed to real geometry
       vs. a tooling limitation of scripted mouse movement. Kept this
       fix anyway since it is a safe, standard, zero-risk hardening
       either way; a real-mouse spot check is still worth a few
       seconds next time someone is on the live site as a Creator. */
    .container-header .mod-menu > li.parent::before {
        content: "";
        position: absolute;
        top: 100%;
        left: 0;
        width: max(100%, 12rem);
        height: 0.4rem;
    }
}