/* alliance-homecare/assets-src/location-selector.css
   Header nav location selector + site-wide phone-number/nav-util layout
   styling. Runs on every page via the header template part — not specific
   to the Request Care drawer/form (see the sibling request-care.css for
   that). Split out 2026-09-16 from what used to be one combined file.
   Deploy via inc/scripts.php enqueue (see that file) alongside
   location-selector.js.
*/

/* Location selector.
   Text stays as originally designed ("Need care in: [Location]") — the
   header row itself is widened below instead of shrinking this label.
   Visibility (mobile-hidden / desktop-shown) is inherited from the
   theme's own compiled CSS rule for this exact position:
     .nav-util > *:first-child { display: none; }              (mobile)
     .nav-util > *:first-child { display: flex; margin-right: ... }  (desktop) */
.ahc-location-selector {
	position: relative;
	flex: 0 0 auto;
	/* Breathing room from the divider (.nav-util:before) immediately to
	   the left. Note: nav-util's own margin-left does NOT create this
	   gap — it shifts nav-util's whole box (divider included) as a unit,
	   so the divider-to-text distance stays the same regardless of that
	   margin. This has to be padding on the location selector itself. */
	padding-left: 10px;
}

/* Mobile nav-util layout (the "Need care in:" selector, phone, Request Care,
   Careers, in that source order): puts phone + location selector on one
   row and gives Request Care / Careers each their own full-width row
   below, instead of leaving all 4 items to wrap wherever they happen to
   land by available width. Before this rule the location selector was
   mobile-hidden entirely (see comment above) and phone + Request Care
   wrapped onto row 1 together with Careers alone on row 2 — this instead
   un-hides the selector and explicitly re-sequences all 4 items.

   Targeted by nav-util's direct-child position (nth-child), not by
   class, because Request Care and Careers share the exact same wrapper
   class (`wp-block-button is-style-fill`) — only their inner <a href>
   differs, and the flex-basis has to land on the wrapper div itself
   (the actual flex item nav-util lays out), not the inner link. If this
   block's markup order in the header template part ever changes, these
   nth-child indices have to change with it. */
@media (max-width: 768px) {
	.nav-util > .ahc-location-selector {
		/* Overrides the theme's own `.nav-util > *:first-child { display:
		   none }` mobile rule referenced above. */
		display: flex !important;
		order: 2;
		/* 50/50 split with Request Care/Careers full-width below meant
		   phone + location ended up pinned to the row's outer edges
		   (nav-util's own justify-content: space-between, inherited from
		   the theme). Centering each half's own content overrides that so
		   both sit centered within their half instead.
		   flex-basis:0 (not 50%) — nav-util has its own column-gap between
		   flex items, so two items at a literal 50% basis each add up to
		   more than 100% once the gap is added on top, and flex-wrap:wrap
		   drops the second one to its own line. flex-basis:0 has both
		   items split whatever space is actually left after the gap. */
		flex: 1 1 0;
		min-width: 0;
		justify-content: center;
		/* This padding-left was breathing room from the divider in the
		   original edge-pinned layout; centered in its own column, it
		   would just push the text off-center, so zero it here. */
		padding-left: 0;
		margin-bottom: 10px;
	}

	.nav-util > *:nth-child(2) {
		/* phone button wrapper */
		order: 1;
		flex: 1 1 0;
		min-width: 0;
		justify-content: center;
	}

	/* The phone link itself (not just its wrapper div above) — targeted
	   by data-phone-market-link, not the literal tel: href, since the
	   href value changes per market via JS. */
	.nav-util a[data-phone-market-link] {
		display: flex !important;
		justify-content: center !important;
		align-items: center !important;
	}

	.nav-util > *:nth-child(3) {
		/* Request Care button wrapper */
		order: 3;
		flex: 1 0 100%;
	}

	.nav-util > *:nth-child(4) {
		/* Careers button wrapper */
		order: 4;
		flex: 1 0 100%;
	}
}

.ahc-location-selector__trigger {
	background: none;
	border: 0;
	cursor: pointer;
	color: inherit;
	display: inline-flex;
	align-items: center;
	gap: 4px;
	padding: 0;
	font-size: var(--wp--preset--font-size--small, 14px);
	line-height: 1.2;
	white-space: nowrap;
}

/* .eh-part-head (the whole header bar) inherits 80px left/right padding
   at this breakpoint from the site-wide rule
   `.wp-site-blocks > :where(header, main, footer, .head-aux)` — the
   same --wp--custom--spacing--outer value every section on the page
   uses, so the header stays edge-aligned with page content below it.
   That's 160px of the header's own horizontal space spent on margin
   instead of nav content — exactly what was short. Client confirmed
   losing that alignment with page content is an acceptable trade for
   fixing the overflow, so this narrows the header's own side padding
   without touching the shared --wp--custom--spacing--outer variable
   (page content below the header keeps its normal margin). */
.eh-part-head {
	/* Was 20px — tightened further after testing with a real selected
	   location ("New Jersey") instead of the "Select Location"
	   placeholder: the placeholder is shorter than most real location
	   names, so it understated how much the "Need care in: [Location]" label
	   actually collides with the divider next to the search icon at
	   1200-1300px. Verified with "New Jersey" selected: no overlap past
	   the divider at 8px. */
	padding-left: 8px !important;
	padding-right: 8px !important;
}

/* Header was hard-coded to a 3-column grid sized for exactly the old
   3 nav-util items (phone / Request Care / Careers); adding the
   location selector as a 4th item overflowed that fixed-width column
   and caused it to overlap the main menu.

   Root cause confirmed: .eh-part-head__inner (the header's outer
   flex/grid container: logo column + this nav column) is capped at
   max-width: var(--wp--style--global--wide-size), which resolves to
   1284px sitewide (--wp--custom--width--wide). Near/above that width
   the header never gets any wider even though the viewport has more
   room — so redistributing percentages inside .eh-part-head__nav alone
   was just re-slicing the same too-small fixed budget.

   First attempt removed the cap entirely (max-width: none), which
   over-corrected: nav-util's gap is set by the theme as
   clamp(.5rem, .9375vw, var(--wp--custom--spacing--x-small)) — a
   viewport-relative value (vw is always relative to the full browser
   viewport, not this container, so removing the cap didn't change the
   gap formula itself), but the 45%-wide nav-util column now had far
   more room than its content needs, so the right-aligned buttons sat
   inside an oversized box and read as sprawled out. Fix: cap the
   header at a modest, fixed width instead of uncapping it (enough
   room for the 4th item, not unlimited), and pin nav-util's gap to a
   fixed value instead of the viewport-scaled one so spacing between
   items is deterministic regardless of screen width. Both only affect
   the desktop grid layout — the mobile/tablet version of
   .eh-part-head__nav uses flex/none, where these properties don't
   apply. */
.eh-part-head__inner {
	max-width: 1440px !important;
	/* .eh-part-head__logo is display:flex; width:100% and stretches to
	   fill whichever grid track it's given — the fixed 22.14% first
	   column is wider than the 200px logo actually needs (the mobile
	   hamburger/search icons that used to justify-content:space-between
	   against it are display:none!important at this breakpoint), so
	   that leftover ~60-80px was dead space.

	   First attempt used `max-content` for the logo column, expecting it
	   to shrink to the logo's real footprint — instead it produced an
	   even bigger gap between logo and nav-main. Root cause: the logo
	   column's own grid item (.eh-part-head__logo) has an explicit
	   `width:100%` set in the theme's CSS, and percentage widths don't
	   contribute to a `max-content` track's intrinsic-size calculation
	   (they're relative to the very track being measured, so browsers
	   treat them as `auto` for that calculation) — the resulting
	   fallback sizing wasn't the tight ~220px expected. Rather than
	   keep guessing at grid-sizing keywords against an unfamiliar
	   cascade, use a concrete fixed pixel width instead: 200px logo +
	   var(--wp--custom--spacing--small) padding-right (already applied
	   inside .eh-part-head__logo) + a small buffer. */
	grid-template-columns: 240px 1fr !important;
}

.eh-part-head__nav {
	/* Went through several percentage splits (58/42, then 54/46) trying
	   to guess a ratio that fits nav-util's content — every one of them
	   broke again the moment the actual text got longer than whatever
	   was tested against ("Select Location" vs "New Jersey" vs
	   "Westchester" vs "Connecticut" all need different amounts of
	   room), because a percentage column has no idea how wide its
	   content actually is.

	   Structural fix instead of another percentage guess: nav-util
	   (search icon + Need care in/phone/Request Care/Careers — the side that
	   can't gracefully lose space) gets `auto`, which sizes the column
	   to its content's real, current width, whatever that is. nav-main
	   (the menu — decorative, already has font-size/gap squeeze and
	   min-width:0 to wrap/shrink gracefully) absorbs whatever's left via
	   `minmax(0, 1fr)`. Stress-tested with every location name
	   including "Westchester" (the longest) at 1200-1440px: nav-main-to
	   -nav-util gap holds at a constant 96px regardless of viewport,
	   because it no longer depends on guessing a ratio against a
	   viewport-relative width — it's just "give nav-util what it needs,
	   every time." */
	grid-template-columns: minmax(0, 1fr) 48px auto !important;
	/* This grid item's own default min-width is `auto`, which for a grid
	   item resolves to its content's min-content size — i.e. the browser
	   refuses to shrink .eh-part-head__nav below what nav-main + search +
	   nav-util need at minimum, even though the parent grid only hands it
	   a 1fr track. Confirmed live at 1200-1300px viewport: .eh-part-head__nav's
	   own right edge sat 94-159px past .eh-part-head__inner's right edge,
	   which is what pushed the CAREERS button off-screen (not an
	   internal-content problem — nav-util's content fit its own 42%
	   column fine in isolation). */
	min-width: 0;
}

.nav-main,
.nav-util,
.eh-part-head__nav .wp-block-navigation {
	/* Same auto-min-width issue one level down: without this, nav-main
	   and nav-util each refuse to shrink below their own content's
	   min-content size inside their grid track. */
	min-width: 0;
}

/* Between ~1200-1280px there still isn't quite enough room for the
   5-item menu + search + 4-item util bar (Need care in/phone/Request Care/
   Careers) at their natural size — confirmed the menu and util content
   genuinely don't both fit even after min-width:0 lets them shrink to
   their text/button min-content. Squeezing gap/padding/font-size here
   closes most of the gap; full elimination at the narrow end would need
   shorter copy (e.g. drop the "Need care in:" label) or a wider breakpoint,
   which is a content/design call, not a CSS one. */
.nav-main {
	--wp--style--block-gap: clamp(.5rem, 1vw, 1.25rem) !important;
	font-size: clamp(.8125rem, .9vw, .9375rem);
}

.nav-util .wp-block-button__link {
	padding-right: clamp(10px, 1.2vw, 20px) !important;
	padding-left: clamp(10px, 1.2vw, 20px) !important;
	font-size: clamp(.6875rem, .78vw, .8125rem) !important;
}

.ahc-location-selector__trigger {
	font-size: clamp(.6875rem, .78vw, .875rem);
}

.nav-util a[data-phone-market-link] {
	font-size: clamp(.75rem, .82vw, .875rem);
}

/* Vertical alignment: the location trigger (.ahc-location-selector) is
   display:flex with align-items:center, so its text is truly centered
   within its own box. The phone number's wrapper (.wp-block-button, a
   generic Gutenberg button block) is plain display:block and relies on
   its 24px line-height to center the 11px-line-height link inline via
   half-leading — that's not a true 50/50 split (confirmed: the phone
   link's own box sat 1.5px lower than the location trigger's, even
   though both parent boxes were centered against each other correctly
   by nav-util's align-items:center). Forcing this wrapper to flex-center
   its child the same way the location trigger already does removes that
   half-leading discrepancy. */
.nav-util .wp-block-button.is-style-plain {
	display: flex;
	align-items: center;
}

.nav-util {
	/* Was 16px — tightened to 8px because at 1200-1300px viewport the
	   4-item util bar (Need care in/phone/Request Care/Careers) still doesn't
	   fit even with min-width:0 letting it shrink to content; this rule
	   comes after the block above in the cascade (same specificity +
	   !important, so source order decides), which is why the gap tweak
	   has to live here rather than in the squeeze rules above. */
	gap: 8px !important;
}

.ahc-location-selector__trigger strong {
	color: var(--wp--preset--color--primary, #204ce5);
	font-weight: 600;
}

.ahc-location-selector__panel {
	/* Was position:absolute; top:100% — hung directly off the trigger
	   button, mid-header, floating over the hero content below with a
	   gap and its own shadow/border "card" look. Client wants it to drop
	   from the header the way the main nav's dropdowns (.nav-sub —
	   Home Services/FAQs/About) do: flush against the header's bottom
	   edge. Switched to position:fixed anchored to the header height
	   custom property so it tracks the sticky header at any scroll
	   position, instead of position:absolute relative to the trigger.

	   left: a hardcoded `right: 8px` pinned it to the viewport's right
	   edge — nowhere near the trigger once the phone number and two
	   buttons sit between them. request-care.js sets the
	   --ahc-panel-left custom property to the trigger's actual x
	   position (via getBoundingClientRect) each time the panel opens,
	   so this stays correct across breakpoints without a fixed offset. */
	position: fixed;
	/* +6px — client reported the panel still reading as slightly into
	   the header at top: var(--wp--custom--head--height) alone. */
	top: calc(var(--wp--custom--head--height) + 6px);
	left: var(--ahc-panel-left, auto);
	right: auto;
	z-index: 20;
	min-width: 180px;
	background: var(--wp--preset--color--white, #fff);
	border: 1px solid var(--wp--preset--color--border, #e1e1e1);
	border-radius: 4px;
	box-shadow: 0 8px 24px rgba(0, 0, 0, 0.12);
	padding: var(--wp--preset--spacing--x-small, 12px) 0;
}

.ahc-location-selector__panel[hidden] {
	display: none;
}

.ahc-location-selector__option {
	display: block;
	width: 100%;
	text-align: left;
	background: none;
	border: 0;
	padding: 8px var(--wp--preset--spacing--small, 16px);
	color: var(--wp--preset--color--primary, #204ce5);
	cursor: pointer;
	font: inherit;
}

.ahc-location-selector__option[aria-current="true"] {
	font-weight: 700;
	background: var(--wp--preset--color--gray-bg, #f5f5f5);
}

/* Design spec (client-provided mockup, 2026-07-16):
   - underline under "Need care in: [Location]" on hover/expanded, with a
     small blue triangle next to the location name that flips when open
   - "Locations" label above the option list (added as a plain, non-
     interactive div in header.html — it's a heading, not a choice)
   - option hover: #CAD9DD background
   - option selected (aria-current): primary-blue background, white text
   - breathing room between options and the panel edge

   Page-dimming overlay: reuses the existing body.has-overlay mechanism
   (see main.css: `body:after` + `body.has-overlay:after{opacity:1}`) —
   the same one .nav-sub (Home Services/FAQs/About dropdowns) already
   triggers. request-care.js toggles that class on the location
   trigger's open/close instead of adding a second overlay. */
.ahc-location-selector__trigger {
	/* "Need care in:" was inheriting a dark slate color from a parent context
	   — client wants it the same blue family as the bold location name
	   (that one gets its color from .ahc-location-selector__trigger
	   strong below), just not bold. */
	color: var(--wp--preset--color--primary, #204ce5);
}

/* Underline: was border-bottom + padding-bottom, which added 3px to the
   BOTTOM of the trigger's own box only. That's asymmetric box growth —
   it shifted the flex-centered content (both "Need care in:" and the bold
   location name) up by half that, 1.5px, breaking the alignment with
   the phone number fixed earlier (confirmed via getBoundingClientRect:
   trigger/strong centers landed at 52-53.5 vs phone's 53.5). Switched to
   text-decoration to match how the phone number's own underline is
   done — it doesn't add box height, so it can't reintroduce that same
   misalignment.

   Matched to the phone link's own underline spec (thickness, offset):
   text-decoration-thickness: 2px. The line is present at all times
   (text-decoration-line: underline) but transparent by default, then
   transitions to its real color on hover/expanded — animates as a
   colour fade instead of an instant on/off snap, and avoids layout
   shift since the decoration is always reserved, just invisible.

   Scoped to .ahc-location-selector__label (a wrapper around just
   "Need care in:" + the bold location name) rather than the trigger button
   itself, so the underline doesn't extend under the triangle — the
   triangle is the trigger's own ::after, a sibling of this span, not a
   descendant of it.

   text-underline-offset: 7px matches the phone link exactly (confirmed
   via getComputedStyle — the phone link was already 7px, not something
   this needed to introduce). What was still misaligned after matching
   that value: this label inherited line-height: 1.2 from
   .ahc-location-selector__trigger (13.2px, at an 11px font-size), while
   the phone link sits in a tight line-height: 11px (1.0) box. Same
   underline-offset measured from two different box heights lands at two
   different absolute screen positions even though both boxes share the
   same vertical center (nav-util's align-items:center only aligns the
   box centers, not where the offset is measured from inside each box).
   Tightening line-height to match the phone's removes that difference —
   confirmed both boxes now report identical top/bottom via
   getBoundingClientRect. */
.ahc-location-selector__label {
	display: inline-block;
	line-height: 11px;
	text-decoration-line: underline;
	text-decoration-style: solid;
	text-decoration-thickness: 2px;
	/* Underline is present at rest now (not just on hover/expanded) —
	   client wants it always visible, matching the phone link's own
	   always-on underline. */
	text-decoration-color: rgb(90, 130, 174);
	text-underline-offset: 7px;
	transition: all var(--wp--custom--transition--medium);
}

/* Hover/expanded: offset nudges from 7px to 9px — the line drops
   slightly away from the text as a hover cue, animated via the same
   transition as the rest of the label (color is already at full
   opacity so this is a pure offset move, not a fade). */
.ahc-location-selector__trigger:hover .ahc-location-selector__label,
.ahc-location-selector__trigger[aria-expanded="true"] .ahc-location-selector__label {
	text-underline-offset: 9px;
}

.ahc-location-selector {
	position: relative;
}

.ahc-location-selector__trigger:after {
	content: "";
	display: inline-block;
	width: 0;
	height: 0;
	margin-left: 2px;
	flex: 0 0 auto;
	border-left: 4px solid transparent;
	border-right: 4px solid transparent;
	border-top: 5px solid var(--wp--preset--color--primary, #204ce5);
	transition: transform 0.2s ease;
}

.ahc-location-selector__trigger[aria-expanded="true"]:after {
	transform: rotate(180deg);
}

.ahc-location-selector__panel {
	padding: 12px 8px;
}

.ahc-location-selector__panel-label {
	padding: 4px 12px 8px;
	color: var(--wp--preset--color--primary, #204ce5);
	font-size: 12px;
	font-weight: 600;
	opacity: 0.65;
}

.ahc-location-selector__option {
	border-radius: 6px;
	margin: 2px 0;
	padding: 8px 12px;
	transition: background-color 0.15s ease, color 0.15s ease;
}

.ahc-location-selector__option:hover {
	background: #CAD9DD;
}

.ahc-location-selector__option[aria-current="true"] {
	background: var(--wp--preset--color--primary, #204ce5) !important;
	color: #fff !important;
}

/* 2026-08-04: client feedback — header "Need care in: [Location]" label and
   phone number read too small. Fixed 16px instead of the clamp()-scaled
   size from the 1200-1300px squeeze rules above (those exist so the
   4-item nav-util bar doesn't overflow at that narrow range — bumping
   this may need revisiting if it starts overflowing there). Scoped to
   .nav-util so this doesn't also resize data-phone-market-display spans
   elsewhere on the site (footer, hero buttons, etc.), which already have
   their own font-size and aren't part of this complaint. */
.ahc-location-selector__label,
.nav-util [data-phone-market-display] {
	font-size: 16px;
}