/**
 * Header parity fixes, measured against D:\m\header.json (the "MAK Header"
 * Elementor export, post 463800) on 2026-08-10.
 *
 * The header itself is templates/headers/header-v1.php and most of its styling
 * lives in the Additional CSS post (343286). These three rules are here, in a
 * Git-deployed file, rather than appended to that post — see the note on
 * duplication at the bottom of this file.
 *
 * Every rule below wins by SPECIFICITY or !important, never by source order.
 * That is deliberate: this file is enqueued, so it prints at wp_head priority 8,
 * while the Additional CSS post prints at 101 and therefore always wins ties.
 */

/* ---------------------------------------------------------------------------
 * 1. Menu item spacing — export says 16px, live rendered 40px above 1200px.
 *
 * header.json → nav-menu widget 5c610c0e → "menu_space_between": 16px, with no
 * responsive override, so it is 16px at every width the nav is visible.
 *
 * There is already a 16px rule in the Additional CSS post:
 *     .mk-header .header-bottom .main-menu > ul > li            -> (0,3,3)
 * It wins below 1200px, which is why the spacing measured correctly at 992px
 * and only drifted on real desktops. At >=1200px the parent theme's
 *     .layout-fullwidth .ts-header nav.main-menu > ul.menu > li -> (0,4,3)
 * (style.css, inside `only screen and (min-width:1200px)`) outranks it and puts
 * the gap back to 40px. A media query adds no specificity, so the only fix is a
 * more specific selector — this one is (0,5,3) and beats the theme at every
 * width, including the 30px/20px/17px rules it sets at the other breakpoints.
 *
 * Fourth time this exact trap has shown up in this migration: a parent-theme
 * selector that looks simpler but is structurally more specific. Source order
 * only ever breaks ties.
 * ------------------------------------------------------------------------- */
.mk-header .header-bottom .ts-menu nav.main-menu > ul.menu > li {
	margin-right: 16px;
}

.mk-header .header-bottom .ts-menu nav.main-menu > ul.menu > li:last-child {
	margin-right: 0;
}

/* ---------------------------------------------------------------------------
 * 2. The sticky placeholder must never reserve LESS than the real header.
 *
 * The theme's sticky plugin wraps .header-sticky in a .sticky-wrapper
 * placeholder and writes that wrapper's height inline, once, at init. On a cold
 * cache it measured 64px against a real header of 218px, so the page content
 * started 154px too high and the header covered the top of every page. With a
 * warm cache the same measurement lands at 217.425px and nothing looks wrong —
 * which is why this only reproduces on a first visit.
 *
 * While the header is NOT stuck the wrapper has no job to do, so letting it size
 * to its content makes the collapse structurally impossible at any width. The
 * plugin adds .is-sticky to the wrapper the moment the header goes
 * position:fixed, and that state is left alone on purpose: the wrapper has to
 * keep holding the space then, or the page jumps on scroll.
 *
 * Note this is NOT fixed with a hardcoded min-height — the real header is 217px
 * at 1440px, 206px at 992px and 64px at 375px, so any fixed number would
 * over-reserve somewhere. The companion nudge in header-v1.php makes the
 * plugin's stored height correct for the stuck state.
 *
 * Same family as the logo-intrinsic-size bugs elsewhere in this migration: an
 * image with no reserved box makes whatever measures it read the wrong number.
 * ------------------------------------------------------------------------- */
.mk-header .sticky-wrapper:not(.is-sticky) {
	height: auto !important;
}

/* ---------------------------------------------------------------------------
 * 3. Mobile logo — export says 200px, live rendered 150px.
 *
 * header.json → image widget 432c349b is header-logo-white-2.png with
 * "space": 200px (Elementor's image widget maps `space` to max-width), shown
 * only on mobile (hide_desktop/-laptop/-tablet_extra/-tablet). The parent
 * theme's own compiled stylesheet agrees — gostorechild.css has
 * `header .logo img { width: 200px }` — so 200px is the site's configured logo
 * width and the 150px is ours.
 *
 * The 150px comes from an earlier pass, in the Additional CSS post:
 *     .mk-header .logo-wrapper img.mobile-logo  -> (0,3,1)
 * This selector is (0,4,1) and overrides it. The band grows from 50px to match
 * the taller logo (355x72 natural, so 200px wide renders ~41px tall).
 * ------------------------------------------------------------------------- */
@media only screen and (max-width: 767px) {

	.mk-header .header-template .logo-wrapper img.mobile-logo {
		max-width: 200px;
	}
}

/* ---------------------------------------------------------------------------
 * 4. Mobile gap below the header — export says 32px, live rendered 0px.
 *
 * header.json → #mak-header (container 2501885b) carries
 *     "margin_mobile": { bottom: 32 }
 * On desktop that 32px is already present, but it comes from the Navigation
 * container's own margin-bottom:32px — and Navigation is hide_mobile, so on
 * phones the gap disappeared entirely. The homepage showed page content starting
 * at y=125 against a header whose bottom edge is also 125, i.e. flush.
 *
 * Applied to the header element itself, matching where the export puts it, so it
 * stacks with each page's own top spacing exactly as the Elementor container did.
 * (0,2,1) so a bare .ts-header rule cannot take it back.
 * ------------------------------------------------------------------------- */
@media only screen and (max-width: 767px) {

	header.ts-header.mk-header {
		margin-bottom: 32px;
	}
}

/* ---------------------------------------------------------------------------
 * 5. Tighten the logo row — user request 2026-08-10, reference is PRODUCTION.
 *
 * ⚠️ This is the one place that deliberately DEPARTS from header.json. The user
 * sent a stage-vs-production screenshot pair and asked to cut the dead space
 * above and below the logo row. Production's live header is a later revision
 * than the export (container ids 13e4809/4fad4fb/656eab7 vs the export's
 * 66bb6494/2501885b/56e7e46b) and it is 15px/25px where the export computes to
 * 29px/47px. Measured on production at 1440px with the page settled:
 *
 *                       production   stage before   after
 *   strip -> logo top       15px         29px        15px
 *   logo bottom -> menu     25px         47px        25px
 *   main bar height        110px        138px       110px
 *   nav row height          63px         80px        63px
 *   header bottom edge     187px        232px       187px
 *
 * The extra 45px was NOT the export's paddings being wrong — it was four bits of
 * inherited slack sitting inside them, which is why this is fixed by removing
 * the slack rather than by shrinking the paddings:
 *
 *   .header-middle > .container   padding 9px 0   (theme) -> 18px
 *   .ts-menu                      padding 7px 0   (theme) -> 14px
 *   .info.mk-header-phone         padding 12px 0  (theme) -> 24px of a 52px cell
 *                                                            holding 28px of text
 *
 * With those gone, the nav row keeps the export's own `10px 0 16px` and lands on
 * production's 63px exactly (10 + 36 item + 16 + 1 border), with the first menu
 * item at y=134 — production's number. Only the main bar's padding itself is
 * changed, 20px -> 15px, which is what production actually uses.
 *
 * The phone keeps a symmetric 4px so its cell measures 36px like the menu cell;
 * at 0 it would be 28px and the phone number would sit 4px above the menu
 * baseline. The logo is centred in its table-cell, so its 80px box plus 15px of
 * padding is the whole main bar — no separate logo rule needed.
 *
 * ⚠️ TWO THINGS THAT WOULD HAVE MADE THIS SILENTLY DO NOTHING:
 *
 * a) The 20px is not the theme's — it is OUR rule in the Additional CSS post,
 *    `.mk-header .header-middle` at (0,2,0). A rule of the same specificity here
 *    loses, because that post prints at wp_head 101 and this file at 8. Hence
 *    `header.ts-header.mk-header` (0,3,1) rather than the obvious `.mk-header`.
 *    Fifth time specificity has decided the outcome in this migration.
 *
 * b) The whole block is scoped to >=768px on purpose. The Additional CSS rule is
 *    itself inside `@media (min-width:768px)`, and the mobile header is a
 *    different construction — main bar padding 0, a 64px blue bar, nav row
 *    hidden, and responsive.css puts 10px on the container. Unscoped, these four
 *    rules would add ~30px to every phone header for no reason.
 * ------------------------------------------------------------------------- */
@media only screen and (min-width: 768px) {

	header.ts-header.mk-header .header-middle {
		padding-top: 15px;
		padding-bottom: 15px;
	}

	header.ts-header.mk-header .header-middle > .container {
		padding-top: 0;
		padding-bottom: 0;
	}

	header.ts-header.mk-header .header-bottom .menu-wrapper > .ts-menu {
		padding-top: 0;
		padding-bottom: 0;
	}

	header.ts-header.mk-header .header-bottom .info.mk-header-phone {
		padding-top: 4px;
		padding-bottom: 4px;
	}
}

/* ---------------------------------------------------------------------------
 * 6. Dropdown — one line per item, each item in its own box.
 *
 * User request 2026-08-10: "كل اختيار في بوكس و يبقى fit في سطر واحد".
 * "Place a Special Order" was wrapping onto two lines and the items had no
 * separators. Cause: the parent theme's
 *     .ts-header nav > ul.menu li ul.sub-menu   -> (0,3,4)
 * fixes the panel at `width:200px; min-width:200px; padding:33px 30px 26px` with
 * `left:-30px` to cancel its own side padding. A 200px box minus 60px of padding
 * leaves 140px, and that is what breaks the longest label in two.
 *
 * Production sizes the panel to its longest item instead — 156px, padding 0,
 * items at 13px/600 with `7px 15px` and `white-space:nowrap`, separated by
 * `1px solid #EDEDED` on every li but the last, panel radius `0 3px 3px 3px` and
 * shadow `0 0 5px rgba(0,0,0,.15)`. That gives 3 x 34px + 2 dividers = 104px.
 * All of it agrees with header.json's dropdown settings (divider solid 1px,
 * padding_vertical/horizontal_dropdown_item 7/15, the same radius and shadow),
 * so export and production want the same thing here — only stage differed.
 *
 * `left:0` replaces the -30px: with padding gone there is nothing to cancel, and
 * the panel's left edge should sit on the parent item's, as it does on production.
 * The selectors are (0,6,4) to clear the theme's (0,3,4) with room to spare.
 *
 * ⚠️ `left` needs !important and nothing else will do. Everything else in this
 * block won on specificity, but the theme also has
 *     .ts-header .ts-menu > nav > ul.menu > li.ts-normal-menu > ul.sub-menu
 *         { left: -30px !important }
 * and no amount of specificity beats !important — only another !important does.
 * The first deploy of this block looked correct in every respect except the panel
 * still hanging 30px to the left, which is exactly how this failure presents:
 * partial. Same resolution as the Advanced Woo Search border-radius earlier in
 * this migration — match the !important rather than escalate the selector.
 *
 * white-space is set on the link rather than the panel so a future multi-column
 * mega-menu child is unaffected.
 * ------------------------------------------------------------------------- */
.mk-header .header-bottom .ts-menu nav.main-menu ul.menu li ul.sub-menu {
	left: 0 !important;
	width: auto;
	min-width: 0;
	padding: 0;
	background-color: #fff;
	border-radius: 0 3px 3px 3px;
	box-shadow: 0 0 5px rgba( 0, 0, 0, 0.15 );
	list-style: none;
}

.mk-header .header-bottom .ts-menu nav.main-menu ul.menu li ul.sub-menu > li {
	padding: 0;
	margin: 0;
	border-bottom: 1px solid #EDEDED;
}

.mk-header .header-bottom .ts-menu nav.main-menu ul.menu li ul.sub-menu > li:last-child {
	border-bottom: 0;
}

.mk-header .header-bottom .ts-menu nav.main-menu ul.menu li ul.sub-menu > li > a {
	display: block;
	padding: 7px 15px;
	font-size: 13px;
	font-weight: 600;
	line-height: 20px;
	color: #33373D;
	white-space: nowrap;
}

/* ---------------------------------------------------------------------------
 * 7. Hovered top-level item gets the blue pill.
 *
 * Not asked for in words, but it is the third difference visible between the two
 * screenshots the user sent: at the same open state, "Customer Service" is plain
 * blue text on stage and white-on-blue on production. header.json backs
 * production up — the nav-menu widget uses "pointer": "background" with
 * "animation_background": "sweep-down", i.e. the item takes a background on
 * hover, not just a colour change. Reuses the active item's #0173CE and 3px so
 * hover and active read as the same control.
 *
 * Flagged separately so it is easy to drop if unwanted — deleting this block
 * changes nothing else.
 * ------------------------------------------------------------------------- */
.mk-header .header-bottom .ts-menu nav.main-menu > ul.menu > li:hover > a,
.mk-header .header-bottom .ts-menu nav.main-menu > ul.menu > li:focus-within > a {
	background-color: #0173CE;
	color: #fff;
}

/* ---------------------------------------------------------------------------
 * 8. Parent-item arrow — solid, in our blue. User request 2026-08-10.
 *
 * The theme draws it as an icon-font glyph:
 *     nav.main-menu > ul.menu > li.parent > a::after
 *         { content:"\e64b"; font-family:themify; font-size:10px }   -> (0,3,5)
 * A 10px hairline chevron inheriting the menu's #191C1F — which is why it reads
 * as faint. Replaced with a border triangle rather than a different glyph: it is
 * solid by construction, needs no icon font, and stays crisp at any zoom.
 *
 * Colour is #0173CE, the same blue as the active/hover pill beside it, not the
 * theme's #0073CF used for the cart and account icons. The two are a hair apart
 * and both exist in this header; matching the pill is what makes the arrow read
 * as part of the nav.
 *
 * `align-self:center` is required, not decorative — the parent <a> is a flex
 * container, so this ::after is a flex item, and with an explicit height it will
 * not stretch and would otherwise sit at flex-start, i.e. 7px high in the top
 * corner instead of on the text's centre line.
 *
 * ⚠️ The hover/current rule below is NOT optional. Hovering the item paints a
 * #0173CE pill (rule 7) and the active item already has one, so a #0173CE arrow
 * on top of it is invisible — the exact "blue mark on a blue background" failure
 * that made the logo look wrong earlier in this migration. It turns white with
 * the label. Both `parent` and `current_page_*` variants are listed because the
 * theme and WordPress each add their own class for an active ancestor.
 *
 * Selector is (0,6,5) to clear the theme's (0,3,5).
 * ------------------------------------------------------------------------- */
.mk-header .header-bottom .ts-menu nav.main-menu > ul.menu > li.parent > a::after {
	content: "";
	display: block;
	align-self: center;
	width: 0;
	height: 0;
	margin-left: 7px;
	border-top: 6px solid #0173CE;
	border-right: 5px solid transparent;
	border-bottom: 0;
	border-left: 5px solid transparent;
}

.mk-header .header-bottom .ts-menu nav.main-menu > ul.menu > li.parent:hover > a::after,
.mk-header .header-bottom .ts-menu nav.main-menu > ul.menu > li.parent:focus-within > a::after,
.mk-header .header-bottom .ts-menu nav.main-menu > ul.menu > li.parent.current-menu-item > a::after,
.mk-header .header-bottom .ts-menu nav.main-menu > ul.menu > li.parent.current-menu-parent > a::after,
.mk-header .header-bottom .ts-menu nav.main-menu > ul.menu > li.parent.current-menu-ancestor > a::after,
.mk-header .header-bottom .ts-menu nav.main-menu > ul.menu > li.parent.current_page_parent > a::after,
.mk-header .header-bottom .ts-menu nav.main-menu > ul.menu > li.parent.current_page_ancestor > a::after {
	border-top-color: #fff;
}

/* ---------------------------------------------------------------------------
 * 9. Less air between the header and the start of the page. User request.
 *
 * The 62px under the nav row was two separate things stacked:
 *     .mk-header .header-bottom  margin-bottom: 32px   (ours, Additional CSS)
 *     .page-container            padding-top:    30px   (theme, every page)
 * Ours is now zero, so the gap is the theme's 30px alone. Went 32 -> 16 -> 0
 * across two rounds at the user's request; the value is kept as an explicit `0`
 * rather than by deleting the rule, because the 32px still lives in the
 * Additional CSS post and would come straight back.
 *
 * **Deliberately still not touching the theme's 30px** — that one is the page's
 * own top spacing rather than the header's, and it applies to every template, so
 * it is the wrong lever for "space under the header". It is the next dial if this
 * needs to go tighter again.
 *
 * Note this and rule 5 put stage TIGHTER than production, which runs 32px + 30px
 * here. That is the user's explicit call, not drift — see the note on rule 5.
 * `header.ts-header.mk-header` (0,3,1) again, because the 32px is ours at (0,2,0)
 * in the later-printing Additional CSS post, and >=768px again because the nav
 * row is hidden on phones (mobile's gap is rule 4's 32px on the header element
 * itself, left as the export has it).
 * ------------------------------------------------------------------------- */
@media only screen and (min-width: 768px) {

	header.ts-header.mk-header .header-bottom {
		margin-bottom: 0;
	}
}

/* ---------------------------------------------------------------------------
 * CLEANUP OWED — read before editing the Additional CSS post again.
 *
 * Rules 1 and 3 now exist in two places: the superseded originals in the
 * Additional CSS post (343286) and the winning versions here. That is the same
 * "stopgap and real file hold duplicate markup" trap that cost time on the
 * footer, so: when post 343286 is next edited over WP-CLI, delete
 *     .mk-header .header-bottom .main-menu > ul > li          { margin-right:16px }
 *     .mk-header .logo-wrapper img.mobile-logo                { max-width:150px }
 * from it and keep only this file. They are inert while this file is enqueued —
 * both lose on specificity — but a future reader will otherwise find two
 * different numbers for the same thing.
 *
 * They were not removed when this file was written because WP-CLI over SSH was
 * unavailable in that session, and the Additional CSS post is only reachable
 * that way (the custom_css post type is not exposed over the REST API, and the
 * site's MCP server only exposes WooCommerce and Rank Math abilities).
 * ------------------------------------------------------------------------- */