/**
 * Header submenu (dropdown) readability hotfix for Tokyo Studio Capture.
 *
 * Phase 1C.3.4a: narrowly scoped fix for Astra's default submenu panel,
 * which ships as a 240px white box with a drop shadow (astra/assets/css/
 * minified/main.min.css: `.sub-menu{width:240px;background:#fff;...}` and
 * `.sub-menu{box-shadow:0 4px 10px -2px rgba(0,0,0,.1)}`), and which becomes
 * nearly unreadable on the homepage Transparent Header specifically, where
 * Astra's own transparent-header dynamic CSS drives the submenu panel/link
 * background and text color from separate, largely-unset-by-default
 * Customizer fields (astra/inc/addons/transparent-header/classes/
 * dynamic-css/dynamic.css.php).
 *
 * Deliberately scoped to submenu/dropdown elements only -- never touches
 * .main-header-menu itself (the top-level bar), which is what produced the
 * "dark rectangle behind the whole menu" regression when this was attempted
 * via the Customizer's Primary Menu > Design controls: those controls
 * target `.main-header-menu, .main-header-menu .sub-menu` together in one
 * combined rule (astra/inc/builder/type/header/menu/dynamic-css/
 * dynamic.css.php, ~line 190) -- there is no separate submenu-only
 * background control in Astra's Customizer.
 *
 * Header typography, top-level menu background, mobile/off-canvas styling,
 * and header height/layout are all untouched here -- separate, later work
 * per the Phase 1C.3 specification.
 */

/**
 * Normal (solid) header -- submenu panel.
 *
 * [class*="ast-builder-menu-"] is used instead of a hardcoded index (e.g.
 * .ast-builder-menu-1) because the exact numbered class assigned to the
 * "Primary Menu" component depends on Header Builder's live component
 * configuration, which cannot be verified from local source -- this is the
 * same attribute-selector technique Astra's own transparent-header CSS uses
 * for the identical reason.
 *
 * Specificity (0,3,0,0), matching or exceeding every relevant Astra rule for
 * these properties: .ast-builder-menu-N .sub-menu (border/radius) is
 * (0,2,0,0); .ast-builder-menu-N .main-header-menu .sub-menu (background) is
 * (0,3,0,0). At matched specificity this wins on source order alone, since
 * this stylesheet is enqueued after Astra's dynamically-generated inline
 * CSS. No !important needed here.
 */
[class*="ast-builder-menu-"] .main-header-menu .sub-menu {
	background: var(--tsc-surface-raised);
	border: 1px solid var(--tsc-border);
	border-radius: 8px;
	box-shadow: none;
}

[class*="ast-builder-menu-"] .main-header-menu .sub-menu .menu-link {
	color: var(--tsc-text);
}

[class*="ast-builder-menu-"] .main-header-menu .sub-menu .menu-link:hover,
[class*="ast-builder-menu-"] .main-header-menu .sub-menu .menu-item:hover > .menu-link,
[class*="ast-builder-menu-"] .main-header-menu .sub-menu .menu-item.current-menu-item > .menu-link {
	color: var(--tsc-accent);
}

/**
 * Homepage Transparent Header -- submenu panel and links.
 *
 * Astra's transparent-header module drives these same two properties from
 * its own dynamic CSS using unusually deep, multi-alternative selector
 * lists (5-7 chained classes per rule, covering flyout/fullscreen mobile
 * edge cases as well as the standard desktop case). Reliably out-specifying
 * every one of those alternatives with a hand-written selector would
 * require mirroring that same fragile complexity for no real benefit.
 *
 * !important is used here deliberately and narrowly: only for
 * background-color and color, only within .ast-theme-transparent-header,
 * nowhere else in this file. Border/radius/shadow do NOT need a transparent-
 * specific override -- Astra's transparent-header CSS never touches those
 * properties on the submenu, so the solid-state rule above already applies
 * universally, in both header states.
 */
.ast-theme-transparent-header [class*="ast-builder-menu-"] .main-header-menu .menu-item .sub-menu {
	background-color: var(--tsc-surface-raised) !important;
}

.ast-theme-transparent-header [class*="ast-builder-menu-"] .main-header-menu .menu-item .sub-menu .menu-link {
	color: var(--tsc-text) !important;
}

.ast-theme-transparent-header [class*="ast-builder-menu-"] .main-header-menu .menu-item .sub-menu .menu-item:hover > .menu-link,
.ast-theme-transparent-header [class*="ast-builder-menu-"] .main-header-menu .menu-item .sub-menu .menu-item.current-menu-item > .menu-link {
	color: var(--tsc-accent) !important;
}

/**
 * Desktop header typography -- Phase 1C.3.3.
 *
 * Scoped to #ast-desktop-header, NOT a breakpoint media query. Astra renders
 * two entirely separate DOM subtrees for its two header presentations --
 * confirmed from source:
 *   astra/template-parts/header/builder/desktop-builder-layout.php:15
 *     <div id="ast-desktop-header" ...>
 *   astra/template-parts/header/builder/mobile-builder-layout.php:16
 *     <div id="ast-mobile-header" class="ast-mobile-header-wrap" ...>
 * Both exist in the page at once; CSS/JS show or hide each depending on
 * viewport. Because each has its own copy of the menu markup, an ID-scoped
 * ancestor selector is a structural guarantee that these rules can never
 * reach anything inside #ast-mobile-header -- not viewport-dependent, not
 * affected by window resizing, and not reliant on Astra's separate
 * .ast-desktop / .ast-header-break-point body classes (which are set from
 * a server-side wp_is_mobile() user-agent check, not a live CSS breakpoint,
 * and so are NOT used here as the scoping mechanism).
 *
 * Astra's own top-level-menu selector, .ast-builder-menu-N .menu-item >
 * .menu-link (astra/inc/builder/type/header/menu/dynamic-css/
 * dynamic.css.php), is a deep descendant selector that matches BOTH
 * top-level and submenu links (a submenu <li class="menu-item"> also
 * satisfies ".menu-item > .menu-link" as a descendant match anywhere
 * inside .ast-builder-menu-N). The two rules below are written to be
 * mutually exclusive instead: "> .menu-item >" targets ONLY direct children
 * of .main-header-menu (top-level items only, never reachable from inside
 * .sub-menu), and the dropdown rule explicitly requires a .sub-menu
 * ancestor (never matches top-level items).
 *
 * Specificity: #ast-desktop-header is an ID selector, so both rules land at
 * (1,4,0,0)/(1,5,0,0) -- comfortably beyond any of Astra's own class-only
 * menu-typography rules (max (0,3,0,0)). No !important needed for either.
 *
 * Only font-family/weight/size/letter-spacing/text-transform are set --
 * color, background, padding, and line-height are left entirely alone, so
 * the currently-validated header geometry and dropdown visuals (commit
 * 2a1f45b, untouched above) are unaffected.
 */
#ast-desktop-header [class*="ast-builder-menu-"] .main-header-menu > .menu-item > .menu-link {
	font-family: var(--tsc-font-body);
	font-weight: 600;
	font-size: 14px;
	letter-spacing: 0.04em;
	text-transform: uppercase;
}

#ast-desktop-header [class*="ast-builder-menu-"] .main-header-menu .sub-menu .menu-item > .menu-link {
	font-family: var(--tsc-font-body);
	font-weight: 500;
	font-size: 14px;
	letter-spacing: normal;
	text-transform: none;
}

/**
 * Account trigger text -- font-family only, per the current account
 * display mode.
 *
 * Astra renders the account trigger's visible label as
 * <span class="ast-header-account-text"> only when the live Customizer's
 * "Login/Profile Type" is set to "text" (astra/inc/builder/controllers/
 * class-astra-builder-ui-controller.php, render_account(); confirmed
 * identical for both the logged-in and logged-out states). If the live
 * site is currently in icon or avatar mode instead, this span simply does
 * not exist in the DOM and this rule matches nothing -- harmless either
 * way, so no live inspection was required to add it safely.
 *
 * Font-family only: size/spacing are deliberately left untouched.
 *
 * The account dropdown's own submenu (Orders/Downloads/Logout, WooCommerce
 * menu mode) was left out of scope this phase -- it was not part of what
 * was asked for ("Account text"), and its markup does not reuse the
 * .sub-menu structure the two rules above target.
 */
#ast-desktop-header .ast-header-account-text {
	font-family: var(--tsc-font-body);
}

/**
 * Site Title / logo: deliberately left untouched this phase.
 *
 * astra/inc/markup-extras.php confirms .site-title a is genuine text
 * (WordPress site-title output), but whether the LIVE site is currently
 * showing that text or a custom-uploaded logo image instead cannot be
 * determined from local source -- Astra's Customizer lets a logo image
 * replace the text entirely. Given that ambiguity, and that the current
 * brand mark is explicitly temporary pending a future redesign, no rule is
 * added here.
 */

/**
 * ================================================================
 * Mobile menu -- Phase 1C.3.6B (corrected).
 * ================================================================
 *
 * CORRECTION: the previous version of this section was scoped under
 * #ast-mobile-popup (the off-canvas drawer). Live DevTools inspection
 * proved that root was wrong for this site -- the mobile header is
 * currently configured in "dropdown" mode
 * (<div id="ast-mobile-header" ... data-type="dropdown">), not off-canvas,
 * so the actual visible mobile menu never renders inside #ast-mobile-popup
 * at all. Every rule under the old root matched nothing, which is why none
 * of that CSS (typography, top-level background) ever visibly applied --
 * the only styling that appeared to work was the darker child-submenu look,
 * and that was coming from the older, broader
 * [class*="ast-builder-menu-"] rules (desktop dropdown section above),
 * which also happen to match .ast-builder-menu-mobile as a substring, not
 * from anything in the (wrongly-scoped) mobile section itself.
 *
 * Verified live DOM (DevTools, TSC RACK's .menu-link):
 *   $0.closest('#ast-mobile-popup')        -> null
 *   $0.closest('.ast-mobile-popup-content') -> null
 *   $0.closest('.ast-builder-menu-mobile')  -> <div class="ast-builder-menu-mobile ast-builder-menu ...">
 *   $0.closest('#ast-mobile-header')        -> <div id="ast-mobile-header" class="ast-mobile-header-wrap" data-type="dropdown">
 *
 * Confirmed structure:
 *   #ast-mobile-header
 *     .ast-builder-menu-mobile
 *       .main-navigation
 *         #ast-hf-mobile-menu.main-header-menu
 *           .menu-item > .menu-link
 *           .menu-item.menu-item-has-children > .sub-menu > .menu-item > .menu-link
 *
 * Root used: #ast-mobile-header .ast-builder-menu-mobile -- an ID plus the
 * real, live-verified component class. This is:
 *   - structurally mobile-only: #ast-mobile-header is a separate DOM
 *     subtree from #ast-desktop-header (astra/template-parts/header/
 *     builder/{desktop,mobile}-builder-layout.php), so nothing here can
 *     reach the desktop header;
 *   - scoped to the menu component specifically via .ast-builder-menu-mobile,
 *     so it cannot reach the logo/photo region, persistent bar, cart, or
 *     hamburger, which live in #ast-mobile-header but outside this
 *     component's own markup.
 *
 * Same background mechanism identified in the earlier (mis-scoped) pass
 * still applies here, just needing the correct root: Astra's mobile-menu
 * dynamic CSS (astra/inc/builder/type/header/mobile-menu/dynamic-css/
 * dynamic.css.php, $selector = '.ast-builder-menu-mobile .main-navigation')
 * paints a background directly on .main-header-menu and on every
 * .menu-link (from the "Menu Background" option), and separately on
 * .sub-menu .menu-link (from "Sub Menu Background") -- both are overridden
 * explicitly below rather than relying on an outer wrapper's background to
 * show through.
 *
 * Specificity: #ast-mobile-header is an ID, so every rule below lands at
 * (1,2,0,0) or higher -- beating Astra's own class-only rules (max
 * (0,5,0,0)) outright, regardless of class count, since an ID always
 * outranks any number of classes. No !important used or needed.
 *
 * The earlier defensive chevron-removal rules (list-style/content/toggle
 * hiding) are intentionally NOT carried forward here. They were written
 * against a scope that never matched anything live, so they were never
 * actually tested against the real chevron issue -- keeping unverified,
 * speculative CSS under a "just in case" rationale is exactly what this
 * project avoids elsewhere. If the leading-chevron issue is still visible
 * once these correctly-scoped rules are live, it should be re-diagnosed
 * against the real DOM (the same way the white background was) and fixed
 * with an evidenced rule, not a defensive block.
 *
 * Astra's native accordion JS, toggle markup, and ARIA/focus behaviour are
 * untouched -- only colour, typography, padding, and border are set below.
 */

/* Top-level menu surface. */
#ast-mobile-header .ast-builder-menu-mobile .main-header-menu {
	background: var(--tsc-bg);
}

#ast-mobile-header .ast-builder-menu-mobile .main-header-menu > .menu-item {
	border-bottom: 1px solid var(--tsc-border);
}

#ast-mobile-header .ast-builder-menu-mobile .main-header-menu > .menu-item:last-child {
	border-bottom: none;
}

#ast-mobile-header .ast-builder-menu-mobile .main-header-menu > .menu-item > .menu-link {
	background: var(--tsc-bg);
	font-family: var(--tsc-font-body);
	font-weight: 600;
	font-size: 15px;
	letter-spacing: 0.035em;
	text-transform: uppercase;
	padding: 18px 20px;
	color: var(--tsc-text);
}

/* Accordion toggle -- colour only; position/rotation/JS untouched. TSC RACK
   has no children, so Astra's walker never emits a toggle for it at all --
   no CSS needed to hide a "fake" one. */
#ast-mobile-header .ast-builder-menu-mobile .ast-menu-toggle {
	color: var(--tsc-text-muted);
}

#ast-mobile-header .ast-builder-menu-mobile .menu-item.ast-submenu-expanded > .ast-menu-toggle {
	color: var(--tsc-accent);
}

/**
 * Homepage-only fix: accordion toggle invisible against the dark mobile
 * menu on the homepage (NAM CAPTURES / PLUGINS / ABOUT).
 *
 * Root cause: Astra core's Elementor-compatibility module ships
 * `.elementor-page .ast-menu-toggle { color: unset !important; }`
 * (astra/inc/compatibility/class-astra-elementor.php:126), unconditionally
 * for any page carrying the `elementor-page` body class (added whenever the
 * page content is edited with Elementor). `!important` beats the two
 * un-flagged rules above regardless of ID specificity, so `color` falls
 * back to `unset` (= inherit), which resolves all the way up to Astra's
 * global default text colour, rgba(0,0,0,.61) -- a dark colour meant for
 * light backgrounds. Composited over this menu's dark background
 * (--tsc-bg, ~rgb(11,11,12)) the arrow becomes visually indistinguishable.
 *
 * Confirmed via live computed-style audit (Playwright, 390px viewport):
 *   - Homepage (body.elementor-page.ast-theme-transparent-header): toggle
 *     `color` computes to rgba(0,0,0,.61) in both the closed and
 *     .ast-submenu-expanded states -- the accent-colour rule above never
 *     visibly applies here either.
 *   - Non-Elementor pages (e.g. WooCommerce product-category archives,
 *     body has no `elementor-page` class): the same two rules above already
 *     win outright and compute to var(--tsc-text-muted) / var(--tsc-accent)
 *     as intended -- left untouched below.
 *
 * `.ast-theme-transparent-header` is this site's homepage-exclusive body
 * class (Astra's Transparent Header add-on, enabled only on the front
 * page), so scoping to it -- rather than matching `.elementor-page`
 * site-wide -- keeps this fix homepage-only, per spec, even though other
 * Elementor-built pages (e.g. /about/) have the same latent conflict.
 *
 * Specificity: 1 ID + 3 classes, `!important` -- beats Astra's
 * `.elementor-page .ast-menu-toggle` (2 classes, `!important`) on
 * specificity, so this wins independent of stylesheet load order.
 */
.ast-theme-transparent-header #ast-mobile-header .ast-builder-menu-mobile .ast-menu-toggle {
	color: var(--tsc-text-muted) !important;
}

.ast-theme-transparent-header #ast-mobile-header .ast-builder-menu-mobile .menu-item.ast-submenu-expanded > .ast-menu-toggle {
	color: var(--tsc-accent) !important;
}

/* Child submenu: nested, one step up from the top-level surface, matching
   the --tsc-bg < --tsc-surface relationship used elsewhere in the token
   system. */
#ast-mobile-header .ast-builder-menu-mobile .sub-menu {
	background: var(--tsc-surface);
}

#ast-mobile-header .ast-builder-menu-mobile .sub-menu .menu-item > .menu-link {
	background: transparent;
	font-family: var(--tsc-font-body);
	font-weight: 500;
	font-size: 14px;
	letter-spacing: normal;
	text-transform: none;
	padding: 12px 20px 12px 36px;
	color: var(--tsc-text);
	border-bottom: 1px solid var(--tsc-border);
}

#ast-mobile-header .ast-builder-menu-mobile .sub-menu .menu-item:last-child > .menu-link {
	border-bottom: none;
}

/* Hover / focus / current state -- top-level and child links alike. */
#ast-mobile-header .ast-builder-menu-mobile .menu-item > .menu-link:hover,
#ast-mobile-header .ast-builder-menu-mobile .menu-item > .menu-link:focus,
#ast-mobile-header .ast-builder-menu-mobile .menu-item.current-menu-item > .menu-link {
	color: var(--tsc-accent);
}

/**
 * ================================================================
 * Desktop header utility cluster (search / account / cart) --
 * Phase 1C.4.
 * ================================================================
 *
 * Scoped to #ast-desktop-header only -- #ast-mobile-header is a separate
 * DOM subtree (see the Phase 1C.3.6B note above) and never contains these
 * three components at all, so nothing here can reach the mobile header.
 *
 * Live-verified (two rounds of Playwright audit, final round against the
 * published Header Builder config: Search moved into
 * .site-header-primary-section-right alongside Account/Cart, Account's
 * Login/Profile Type set to Icon) against https://tokyostudiocapture.com/
 * at 1440/1024/960px. Findings driving each rule below:
 *
 *   - Account's icon (<svg class="account-icon">) ships with a hardcoded
 *     black fill -- confirmed NOT `fill="currentColor"`, unlike Search's
 *     SVG (which already resolves to white via inherited `color` and needs
 *     no rest-state rule here). Left alone, the account icon is invisible
 *     against the dark header in every state, including hover.
 *   - Cart's SVG renders ~27x29px vs. Search/Account's ~16-18x18px, despite
 *     all three being Astra's own icon sets with no inline size override.
 *   - The three utility wrappers currently carry mismatched Astra-default
 *     padding/margin (.ast-header-search and .ast-header-woo-cart: 10px
 *     horizontal padding each; .ast-header-account-wrap: a stale
 *     `margin: 0 -5px 0 -10px` sized for the old "Log In" text label),
 *     producing an uneven 12px/21px visual gap. Removing exactly those
 *     three properties and setting one `gap` on their shared flex parent
 *     (.site-header-primary-section-right, already `display:flex` from
 *     Astra) replaces it with a single consistent value.
 *   - None of the three show any visible hover/focus feedback today.
 *
 * Specificity: #ast-desktop-header is an ID, so every rule lands at
 * (1,2,0,0) or higher -- beating Astra's own class-only rules outright,
 * consistent with every other section of this file. No !important used.
 */

/* Spacing: one consistent gap between the three utility items, replacing
   Astra's mismatched per-item padding/margin. Only the specific properties
   that caused the asymmetry are removed -- nothing else on these elements
   (background, flex layout, click targets) is touched. */
#ast-desktop-header .site-header-primary-section-right {
	gap: var(--tsc-space-3);
}

#ast-desktop-header .ast-header-search,
#ast-desktop-header .ast-header-woo-cart,
#ast-desktop-header .ast-header-account {
	padding: 0;
}

#ast-desktop-header .ast-header-account-wrap {
	margin: 0;
}

/* Account icon visibility: explicit fill on the rendered path/circle, not
   the <svg> wrapper. Live-verified: Astra's own dynamic CSS
   (.ast-header-account-wrap .ast-header-account-type-icon .ahfb-svg-iconset
   svg path:not(.ast-hf-account-unfill), ...svg circle) sets fill directly
   on these two elements, which overrides inheritance from any fill set on
   the parent <svg> -- an svg-level rule here matches nothing that actually
   renders. #ast-desktop-header (an ID) beats that rule's all-class
   selector on specificity alone, no !important needed. */
#ast-desktop-header .ast-header-account-link svg.account-icon path,
#ast-desktop-header .ast-header-account-link svg.account-icon circle {
	fill: var(--tsc-text);
}

/* Optical horizontal correction: box-to-box spacing is already a uniform
   12px on both sides of Account (live-verified), but each icon's own SVG
   artwork carries different internal whitespace, so the visible glyph-to-
   glyph gap is not: 14.57px Search-to-Account vs. 20.81px Account-to-Cart
   at 1440px (live-measured). +3px on Account brings both to ~17.7px. */
#ast-desktop-header .ast-header-account-link svg.account-icon {
	transform: translateX(3px);
}

/* Cart icon size: normalize to match Search/Account's existing ~18px
   glyph size. Search and Account are left untouched -- they are already
   approximately correct. */
#ast-desktop-header .ast-header-woo-cart .ast-icon-shopping-basket svg {
	width: 18px;
	height: 18px;
}

/* Hover / focus: white -> accent, uniformly across all three. */
#ast-desktop-header .ast-header-search .astra-search-icon:hover svg,
#ast-desktop-header .ast-header-search .astra-search-icon:focus svg,
#ast-desktop-header .ast-header-account-link:hover svg.account-icon path,
#ast-desktop-header .ast-header-account-link:hover svg.account-icon circle,
#ast-desktop-header .ast-header-account-link:focus svg.account-icon path,
#ast-desktop-header .ast-header-account-link:focus svg.account-icon circle,
#ast-desktop-header .ast-header-woo-cart .cart-container:hover .ast-icon-shopping-basket svg,
#ast-desktop-header .ast-header-woo-cart .cart-container:focus .ast-icon-shopping-basket svg {
	fill: var(--tsc-accent);
}