/**
 * Miscellaneous site fixes for Tokyo Studio Capture.
 * Migrated from additional-css.txt (Phase 0.1 audit).
 *
 * NOTE (Phase 0.5c/0.5d): the checkout-header rule that used to live here
 * does not belong in any enqueued stylesheet at all -- live verification
 * showed that NO stylesheet (this one, nor a dedicated checkout.css enqueued
 * at wp_enqueue_scripts priority 99) is ever requested on the CartFlows
 * checkout page. It is now emitted as a small inline <style> block directly
 * in wp_head, scoped to checkout requests only. See functions.php ->
 * tsc_checkout_inline_styles().
 */

footer img {
	max-width: 180px !important;
	height: auto !important;
}

/*
 * FOOTER LOGO SIZE -- cross-page consistency fix. Live-audited: the rule
 * above (`footer img`, specificity 0-0-2) rendered the footer logo at
 * 180px on the homepage but 335px on /all-products/ and every product-
 * category archive, despite identical DOM markup
 * (figure.wp-block-image > img inside a Gallery block) and this stylesheet
 * being enqueued on both. Root cause: WordPress only enqueues
 * wp-includes/css/dist/block-library/style.min.css on templates it detects
 * as needing core block styles -- present on WooCommerce archive templates,
 * absent on the Elementor-built homepage. That file's own
 * `.wp-block-gallery.has-nested-images figure.wp-block-image img` rule
 * (specificity 0-3-2, `max-width: 100% !important`) outranks `footer img`
 * (0-0-2) wherever it's loaded, so the logo scaled up to its column width
 * there instead of respecting the 180px cap. Fixed by matching the same
 * real DOM structure with one extra ancestor class so this selector's
 * specificity (0-4-2) always wins, on every page, independent of any
 * plugin/core stylesheet's load order.
 */
.site-primary-footer-wrap .wp-block-gallery.has-nested-images figure.wp-block-image img {
	max-width: 180px !important;
	width: auto !important;
	height: auto !important;
}

/* ============================================================
 * FLOATING CART -- quantity badge color -- Phase 4B
 * ============================================================
 * Component: ModernCart plugin (modern-cart/assets/css/cart.css),
 * `#moderncart-floating-cart .moderncart-floating-cart-count`. The button
 * itself already uses the TSC accent tan (confirmed live, unrelated to
 * this fix, not touched). The badge's bright green came from the plugin's
 * own CSS custom-property theming system -- confirmed live via an inline
 * `<style id="moderncart-cart-css-inline-css">` block the plugin itself
 * generates, setting `--moderncart-floating-count-bg-color: #10B981` on
 * `:root` (its own configured/default color, not a bug in this theme).
 *
 * Fixed the same way the plugin itself is designed to be re-themed --
 * redefining its own custom property, not fighting it with `!important`
 * or a rewritten selector -- scoped to `#moderncart-floating-cart` (an ID,
 * specificity (1,0,0)) so it reliably overrides the plugin's own `:root`
 * definition (specificity (0,1,0)) regardless of stylesheet load order.
 * Uses `--tsc-text-light` (near-black) rather than `--tsc-accent`: the
 * button background already IS the accent tan, so an accent-colored badge
 * on an accent-colored button would have poor differentiation -- the
 * site's own existing dark-badge/light-text convention (used for every
 * primary button elsewhere) gives strong, restrained contrast instead of
 * the "generic plugin notification" green. The plugin's own text color
 * (`--moderncart-floating-count-text-color: #FFFFFF`) already reads
 * correctly against this and is left untouched -- only the background
 * custom property changes, satisfying "smallest possible fix".
 *
 * `-light` variant included alongside for consistency with the plugin's
 * own paired naming (`-bg-color` / `-bg-color-light`) even though no
 * consumer of the `-light` variant was found in the accessible stylesheets
 * during this audit -- harmless if unused, correct if it turns out to be
 * used by inline/JS-driven styling not visible to static CSS inspection.
 */
#moderncart-floating-cart {
	--moderncart-floating-count-bg-color: var(--tsc-text-light);
	--moderncart-floating-count-bg-color-light: var(--tsc-text-light);
}

/* ============================================================
 * HEADER -- Account icon optical vertical alignment -- Phase 4B
 * ============================================================
 * Live-measured (desktop, 1440px): the Account link's own bounding box is
 * ALREADY perfectly center-aligned with Search and Cart -- all three share
 * the identical vertical center (45px from viewport top in the audited
 * screenshot), confirmed via getBoundingClientRect(), not a genuine
 * geometric misalignment. The "reads slightly low" perception is the
 * account glyph's own visual weight (a person-silhouette icon typically
 * has more visual mass in its lower "shoulders" than its upper "head"
 * circle) sitting lower within an already-correctly-centered box -- an
 * optical-alignment nuance, not a layout bug. Scoped to the account link
 * ONLY (a specific, stable Astra class, confirmed live) -- Search and Cart
 * are untouched, per the brief's explicit "do not move Search/Cart unless
 * measurement proves the whole cluster is wrong" (it doesn't). Mobile has
 * no equivalent persistent header icon row to check -- confirmed live
 * (Astra's mobile header shows only the logo and menu toggle; Account/
 * Search live inside the off-canvas menu on mobile, out of this cluster).
 *
 * 2px is a conservative starting nudge, not a measured "correct" value --
 * optical centering is a perceptual judgment call that needs a live look
 * to confirm, flagged in the Phase 4B report.
 */
@media (min-width: 922px) {
	.ast-header-account-link {
		position: relative;
		top: -2px;
	}
}