/*
 * dmd.header-offset.css
 *
 * The shared Stardock header (Dark variant) is a FIXED 33px bar at top:0 / z-index:1000.
 * This site's own chrome is also fixed at top:0 — `nav` at z-index:1000 and `a#nav-menu` at
 * z-index:1002 — so without this file the two overlap and the pirate nav drape renders
 * underneath the corporate bar.
 *
 * Kept separate from the vendored deadmansdraw.css so that stylesheet stays byte-identical to
 * the one production serves (verified in Phase 0), which keeps future diffs against the live
 * site meaningful.
 *
 * Approved decision A1 renders this header even though the live site has none; A5 records the
 * resulting divergence as an approved deviation and scores the page body beneath it.
 *
 * Selector specificity: deadmansdraw.css addresses these elements through long
 * `body > form > ...` chains, so the same chains are repeated here. A bare `nav { top: 33px }`
 * would lose on specificity and silently do nothing.
 */

:root {
    /* 33px, NOT 34px (P3.1: was 34px against the old Stardock.Web.Header RCL). The standalone
       CDN package resets `box-sizing: border-box` on `.header-container` and all its
       descendants (header-dark.css), so the `height: 33px; border-bottom: 1px solid #4b4b4b`
       declaration now includes the border INSIDE the box — the bar occupies exactly 33px
       (getBoundingClientRect().height === 33). The old RCL shipped no such reset, so it ran
       under the page's default `content-box` and the border sat OUTSIDE the declared height,
       making the real bar 34px. Verified against the live CDN CSS directly (fetched
       stardock.cachefly.net/header/v1/header-dark.css) and confirmed visually post-swap. */
    --stardock-header-height: 33px;
}

/* The bar is TALLER on mobile: the package's own `@media(max-width:850px)` sets
   `.header-container { height: 44px }`, which under the same border-box reset occupies exactly
   44px (border included). The breakpoint here must track the package's 850px exactly — this
   site's own breakpoints are 480/768/960 and are unrelated, so reusing one of those would leave
   an 11px mismatch across part of the range. */
@media (max-width: 850px) {
    :root {
        --stardock-header-height: 44px;
    }
}

/* Lift the shared header above this site's own stacked chrome.
 *
 * The library sets `.header-container { position: fixed; z-index: 1000 }`, and because that
 * establishes a STACKING CONTEXT, everything inside it — including the nav dropdowns, which
 * declare z-index 1001 of their own — composites against the page at 1000. It cannot escape
 * its parent's level no matter how high the child's z-index is.
 *
 * MEASURED Z-INDEX STACK (recorded for P4.6, which builds on top of this header):
 *     .header-container  1000   (fixed)     <- the shared header's own default
 *     figure.headimg     1001   (relative)  <- the pirate artwork
 *     a#nav-menu         1002   (fixed)     <- mobile hamburger toggle
 *     div#mobilenav      2000   (fixed)     <- slide-in mobile panel
 *     .header-container  2001   (fixed)     <- THIS FILE's override, below, so header dropdowns
 *                                              clear all three of the above
 *
 * So a header dropdown opening downward was painted UNDER figure.headimg. Confirmed by
 * hit-test: document.elementFromPoint() at the open submenu's own coordinates returned
 * div.fixedratio (inside figure.headimg) rather than the submenu.
 *
 * It only reproduced at the top of the page: dmd.index.js InitNav() sets figure.headimg to
 * z-index 1001 while scrollTop <= 1 and drops it to 0 once scrolled, which is why the
 * dropdowns behaved correctly further down the page.
 *
 * Fixing it here rather than lowering figure.headimg: that 1001 is deliberate site design (the
 * artwork is meant to overlap the drape nav) and is re-applied by JS on every scroll event, so
 * a CSS override would be fought by the script. Raising the header is the targeted change.
 *
 * 2001 clears all three, including #mobilenav. The two never overlap in practice — the mobile
 * panel is offset to start below the bar — so this only decides the dropdown case.
 *
 * Purely a paint-order change: it alters nothing until a dropdown is open, and the static
 * pixel comparison against the live site remains 0 differing pixels at all three viewports.
 *
 * SELECTOR RE-VERIFIED FOR P3.1 (CDN custom element): `id="stardock-header"` is not a Razor
 * artifact — the standalone package's own render function emits BOTH `id="stardock-header"`
 * and `class="header-container"` on the same element (confirmed by fetching header.js
 * directly: `class: "header-container", id: "stardock-header"` in its dark-variant render). So
 * this selector needed no change when the Razor component was replaced with <stardock-header>.
 */
#stardock-header.header-container {
    z-index: 2001;
}

/* Push the whole document below the fixed corporate bar. `.innerwrapper` is in normal flow,
   so body padding moves it; the fixed children below need their own offset.

   background-position must move with it. deadmansdraw.css anchors the page background at
   `center top` (and re-declares it in the <=480px media query), which is the body's
   padding-box origin — unaffected by padding-top. Left alone, the content shifts down 33px
   while the scattered-cards artwork stays put, so every card sits 33px off relative to the
   live site. A pixel diff of the port against live showed exactly that: content blocks
   identical, background misaligned by the header height. Re-anchoring it here keeps the
   artwork/content relationship byte-identical to live.

   Declared unconditionally and loaded last, so it also wins over the shorthand `background:`
   inside the <=480px media query — media queries add no specificity. */
body {
    padding-top: var(--stardock-header-height);
    background-position: center var(--stardock-header-height);
}

/* This site's fixed pirate nav (the drape banner). */
body > form > div.innerwrapper > nav {
    top: var(--stardock-header-height);
}

/* The mobile hamburger toggle, fixed at top-left. */
body > form > div.innerwrapper > div.content > a#nav-menu {
    top: var(--stardock-header-height);
}

/* The slide-in mobile nav panel is fixed and full-height; start it below the bar and shorten
   it by the same amount so its bottom edge still meets the viewport floor. */
body > form > div#mobilenav {
    top: var(--stardock-header-height);
    height: calc(100% - var(--stardock-header-height));
}

/* The shared header's own mobile account drawer anchors at top:50px, which is tuned for the
   50px light variant. Re-anchor it to the 33px dark bar so it does not float detached. */
@media (max-width: 850px) {
    #account-menu {
        top: var(--stardock-header-height);
        max-height: calc(100vh - var(--stardock-header-height));
    }
}