/**
 * Targeted theme-side fixes (see inc/theme-overrides.php's header comment).
 * Never edits the carried Oxygen CSS.
 *
 * @package KSM_Select_Paving
 */

/*
 * Stage 3.3a review round: Review Collector's own slider markup
 * (.ksm-style2-track-clip, inside .ksm-testimonial-latest-wrapper - the
 * wrapper kept verbatim in template-parts/reusable/reusable-5390-latest-
 * reviews.php) has an unconstrained horizontal track (scrollWidth ~7300px on
 * a 1440px viewport, RC's own slider mechanism). .ksm-testimonial-latest-
 * wrapper is display:flex with overflow-x:visible (from the carried
 * "width--1600" utility class) and its single flex child
 * (.ksm-widget.ksm-style-2) has the browser's default flex-item
 * min-width:auto, so it refuses to shrink below its own oversized content
 * and the overflow bleeds out through every ancestor up to <body>
 * (confirmed via computed-style walk: .ksm-testimonial-latest-wrapper's own
 * width is correctly 1440px, but overflow-x:visible lets the 2113px-wide
 * child paint past it, and document.body.scrollWidth read back 2123px
 * instead of the 1440px viewport). Fixed by containing the overflow at this
 * one wrapper - scoped to the reviews region only, RC's own CSS/markup is
 * untouched (never patch the master plugin).
 */
/*
 * [Stage 3.3a review round, REMOVED in the 3rd correction] A forced
 * #image-2727-3650{width:322px;height:172px} rule lived here briefly, to
 * paper over the wrong logo attachment being used (id 3703, no 300x150 size
 * of its own). Manager's parity finding: the baseline (and live) actually
 * render a DIFFERENT attachment entirely (id 2331, "logo_top_main", which
 * DOES have a real registered 300x150 `medium` size) - header.php now reads
 * that via the new Company Details field `sitewide_header_logo` (code
 * default 2331). With the correct file behind it, the carried CSS alone
 * (no override) already produces the exact baseline box - verified: removing
 * this rule entirely still measures 322x172 at desktop, so it's gone rather
 * than left in as a no-op.
 */

.ksm-testimonial-latest-wrapper {
	overflow-x: hidden; /* safety net only, kept in case a future RC markup change reintroduces overflow - the real fix is the flex-item rule below. */
	max-width: 100%;
}

/*
 * [2nd pass] overflow-x:hidden above only clipped the symptom - RC's slider
 * widget (.ksm-widget.ksm-style-2, the direct flex CHILD of
 * .ksm-testimonial-latest-wrapper) renders at its own explicit ~2112px width
 * regardless of the 1440px flex parent, because a flex item's default
 * min-width:auto lets it refuse to shrink below its own content/explicit
 * width. Clipping it at the wrapper just cut a card in half instead of
 * showing two whole ones for columns=2. Forcing the flex item to actually
 * size to the available space (not its own content) fixes the real cause:
 * every nested wrapper inside it (.ksm-widget-container, .ksm-style2-panel,
 * .ksm-reviews-container-wrapper, .ksm-style2-track-clip) is a block/flex
 * descendant that sizes off ITS parent's width, so constraining this one
 * flex item cascades the fix all the way down without touching RC's own
 * CSS/markup anywhere.
 */
.ksm-testimonial-latest-wrapper > .ksm-widget.ksm-style-2 {
	min-width: 0;
	flex: 1 1 auto;
	width: 100%;
}

/*
 * [Stage 3.3a review round] WCAG AA contrast fix: <strong>187 reviews</strong>
 * in RC's summary rail was rendering #2b385b on the rail's blue background
 * (2.33:1, fails AA). LIVE already carries this exact fix in its own
 * universal.css - copied verbatim (not re-derived) per the review's
 * instruction, from stage-3/drift/css-diff/.
 */
.ksm-style-2 .ksm-style2-rail-count strong {
	font-weight: 700;
	color: #fff !important;
}

/*
 * [Stage 3.5 fix list, item a] single.php's CTA section (#section-554-2744,
 * "Want to Discuss The Work?"): the KSM form measured 460px wide vs the
 * baseline GF form's 748px in this SAME flex-shrink context, making the
 * whole section 1099px tall vs the baseline's 764px. Root cause traced
 * (getComputedStyle walk, same technique as the #code_block-834-3643 flex-
 * child-width fix): #section-554-2744's own .ct-section-inner-wrap is
 * display:flex;flex-direction:row - div_block-557-2744 (the white form
 * card) is a flex item with no explicit width/flex-basis, so it shrinks to
 * its own min-content width. The baseline's Gravity Forms markup happened
 * to carry a `<textarea cols="50">` (a real HTML sizing attribute, not CSS),
 * which alone gives its container a ~450-500px intrinsic minimum before any
 * CSS is applied; KSM Forms' own textarea (class-ksm-forms-renderer.php)
 * carries no such attribute, so it shrinks to the browser's much narrower
 * UA-default. Confirmed via measurement THIS IS THE ONLY affected host:
 * the SAME .ksm-contact-form on page 367 (Contact Us) and page 3999
 * (Driveways) already measures 1354px/1400px, matching GF's own baseline
 * width there exactly - those containers are plain wide blocks, not a
 * flex-shrink-to-fit row, so no theme CSS needed for them. Fixed here with
 * an explicit min-width on the form itself, scoped to this ONE host only
 * (never edit the plugin's own CSS) - matches the baseline's measured
 * number, capped so it can never overflow a narrower viewport.
 */
#section-554-2744 .ksm-contact-form {
	min-width: 748px;
	max-width: 100%;
}

@media (max-width: 800px) {
	#section-554-2744 .ksm-contact-form {
		min-width: 0;
	}
}

/*
 * [Stage 3.5 fix list, item k] WPGB facet bar base rules - WP Grid
 * Builder's OWN plugin CSS supplies these (list-style reset, fieldset/
 * legend reset, .wpgb-sr-only visually-hidden pattern, basic checkbox row
 * layout) but that plugin is not, and should not be, active/enqueued on
 * this build (Stage 5 replacement item). The carried PER-INSTANCE CSS
 * (assets/oxygen/post/5991.css, 3709.css) only has colour/spacing/sizing
 * overrides scoped to each facet id - it assumes this base layer already
 * exists. Scoped to .oxy-wpgb-facet so it only ever touches these
 * hand-built facet bars, never any other list/fieldset in the theme.
 */
.oxy-wpgb-facet fieldset {
	border: 0;
	margin: 0;
	padding: 0;
}
.oxy-wpgb-facet .wpgb-sr-only {
	position: absolute;
	width: 1px;
	height: 1px;
	padding: 0;
	margin: -1px;
	overflow: hidden;
	clip: rect(0, 0, 0, 0);
	white-space: nowrap;
	border: 0;
}
.oxy-wpgb-facet ul.wpgb-hierarchical-list {
	list-style: none;
	margin: 0;
	padding: 0;
}
/*
 * [Stage 3.5 fix list, item y] Real WPGB checkbox skin - values pulled
 * directly from the plugin's OWN frontend CSS
 * (wp-content/plugins/wp-grid-builder/frontend/assets/css/facets.css, read
 * on the server since the plugin isn't shipped in this repo), not
 * guessed. The plugin's own markup is a JS-driven `<a role="checkbox"
 * aria-pressed="...">` with NO real form input at all - this theme
 * deliberately keeps a REAL `<input type="checkbox">` instead (the
 * sanctioned no-JS-safe form, established at item k), so the native input
 * is made VISUALLY invisible but stays in normal flow, focusable and
 * keyboard-operable (opacity:0, not display:none/visibility:hidden, and
 * NOT the sr-only clip pattern - clicking/tabbing to it must still hit its
 * own hit-box, not just the label text) and the checked/focus states are
 * driven by real `:checked`/`:focus-visible` CSS on the sibling
 * `.wpgb-checkbox-control`, replacing WPGB's own `[aria-pressed]` selectors
 * (which never apply to a real input) with the equivalent input pseudo-
 * classes.
 */
.oxy-wpgb-facet .wpgb-checkbox {
	display: flex;
	align-items: center;
	position: relative;
	margin: 0;
	padding: 0;
	line-height: 1;
	list-style: none;
	cursor: pointer;
}
.oxy-wpgb-facet .wpgb-checkbox input[type="checkbox"] {
	position: absolute;
	top: 0;
	left: 0;
	width: 20px;
	height: 20px;
	margin: 0;
	padding: 0;
	opacity: 0;
	cursor: pointer;
}
.oxy-wpgb-facet .wpgb-checkbox-control {
	position: relative;
	display: flex;
	align-items: center;
	justify-content: center;
	flex-shrink: 0;
	height: 20px;
	width: 20px;
	border-radius: 4px;
	border-style: solid;
	border-width: 2px;
	border-color: #c7c7c7;
	transition: border-color ease 0.25s, background-color ease 0.25s;
}
.oxy-wpgb-facet .wpgb-checkbox:hover .wpgb-checkbox-control {
	border-color: #949494;
}
.oxy-wpgb-facet .wpgb-checkbox input[type="checkbox"]:focus-visible + .wpgb-checkbox-control {
	outline-width: 1.5px;
	outline-offset: 2px;
	outline-color: Highlight;
	outline-color: -webkit-focus-ring-color;
	outline-style: solid;
}
.oxy-wpgb-facet .wpgb-checkbox input[type="checkbox"]:checked + .wpgb-checkbox-control {
	border-color: #0069ff;
	background: #0069ff;
}
.oxy-wpgb-facet .wpgb-checkbox-control:after {
	content: "";
	position: relative;
	top: -1px;
	height: 10px;
	width: 6px;
	border: solid transparent;
	border-width: 0 2px 2px 0;
	box-sizing: border-box;
	transform: rotate(45deg) scale(0);
	transition: transform ease 0.25s, border-color ease 0.25s;
}
.oxy-wpgb-facet .wpgb-checkbox input[type="checkbox"]:checked + .wpgb-checkbox-control:after {
	transform: rotate(45deg) scale(1);
	border-color: #fff;
}
.oxy-wpgb-facet .wpgb-checkbox-label {
	flex: auto;
	margin: 0;
	font-size: 16px;
	font-weight: normal;
	line-height: 20px;
	cursor: pointer;
	padding: 0 0 0 8px;
}
/*
 * [Stage 3.5 fix list, item y] `.wpgb-facet-title` (the H4/legend text) had
 * no explicit line-height/margin of its own - it was falling back to this
 * theme's generic H4 styling (18px), where the plugin's own value is a
 * fixed 24px with a 24px bottom margin (facets.css:
 * `.wpgb-facet-title{font-size:20px;line-height:24px;padding:0;margin:0 0
 * 24px 0}`) - confirmed via the persection measurement JSON that this ONE
 * value accounted for most of facet-5's (search) height shortfall.
 */
.oxy-wpgb-facet .wpgb-facet-title {
	font-size: 20px;
	line-height: 24px;
	padding: 0;
	margin: 0 0 24px 0;
}
.oxy-wpgb-facet .wpgb-search-facet {
	position: relative;
}
/*
 * [Stage 3.5 fix list, item y] The LABEL wrapping the search input was
 * shrinking to its content's width (measured 387px instead of the
 * baseline's full 1380px) - WPGB's own CSS makes it a flex container
 * (`display:flex`) but relies on it being the ONLY item in a block-level
 * parent to naturally take full width; something in this theme's own
 * label/flex defaults was capping it instead, so `width: 100%` is added
 * explicitly here (the plugin's own CSS never needed to say this, but this
 * theme does).
 */
.oxy-wpgb-facet .wpgb-search-facet label {
	position: relative;
	display: flex;
	width: 100%;
}
.oxy-wpgb-facet .wpgb-input,
.oxy-wpgb-facet input[type="search"].wpgb-input {
	position: relative;
	vertical-align: middle;
	appearance: none;
	height: 40px;
	min-height: 40px;
	width: 100%;
	margin: 0;
	padding: 6px 32px;
	background: none;
	border-width: 2px;
	border-style: solid;
	border-color: #c7c7c7;
	border-radius: 4px;
	line-height: 24px;
	font-size: 16px;
	font-weight: 400;
	outline: none;
	transition: border-color 100ms ease;
	box-sizing: border-box;
}
.oxy-wpgb-facet .wpgb-input:hover {
	border-color: #949494;
}
.oxy-wpgb-facet .wpgb-input:focus {
	border-color: #2a2a2a;
}
.oxy-wpgb-facet .wpgb-input-icon {
	position: absolute;
	top: calc(50% - 8px);
	right: 10px;
	height: 16px;
	width: 16px;
	pointer-events: none;
	color: #c7c7c7;
}
/*
 * [Stage 3.5 fix list, item y] facet-17's "See More Projects" button
 * (.wpgb-load-more) was inheriting this theme's own generic button
 * padding/line-height instead of WPGB's own `.wpgb-button` base rule -
 * confirmed via a live computed-style comparison against baseline-now
 * (padding 15px 36px, line-height 20px, font-size 18px - candidate had
 * 1px 6px / 32.4px before this fix, giving a 38px box instead of the
 * baseline's 54px). The 2px solid border colour/radius are already
 * correctly carried via assets/oxygen/post/5991.css's own per-instance
 * override for this facet id - only the base padding/line-height/font-
 * size were missing, from the plugin's own facets.css `.wpgb-button` rule.
 *
 * [Stage 3.5 fix list, item dd1] `color: #fff` added - a first-pass
 * assumption that this was already "superseded" by the carried 5991.css
 * override was WRONG (that file only sets background-color, border colours
 * and text-align for this facet, never `color`) - confirmed via a live computed-
 * style diff that the candidate's button text was rendering black
 * (inherited) against baseline's white, re-checked after the fact rather
 * than assumed correct the first time.
 */
.oxy-wpgb-facet .wpgb-button {
	height: auto;
	margin: 0;
	padding: 15px 36px;
	color: #fff;
	font-size: 18px;
	font-weight: 500;
	line-height: 20px;
	letter-spacing: 0;
	text-transform: none;
	cursor: pointer;
}
/*
 * [Stage 3.5 fix list, item y] facet-7's checkbox row padding: confirmed
 * via the same live baseline-now comparison that `.wpgb-checkbox` for
 * THIS facet gets 10px padding on the wrapping label - unlike facet-6's
 * checkbox rows, which have none (measured 0px there, matching this
 * theme's own generic `.wpgb-checkbox` rule already). Manager's own note
 * that per-facet spacing "differs... don't normalise" is correct - this is
 * WPGB's own per-facet "choices padding" builder setting (injected at
 * runtime, no static CSS source to copy from), so it is hardcoded here,
 * scoped to this one facet id, exactly as the carried 5991.css does for
 * this same facet's OTHER per-instance values.
 */
#-wpgb-facet-7-5991 .wpgb-checkbox {
	padding: 10px;
	box-sizing: border-box;
}
/*
 * [Stage 3.5 fix list, item y] facet-6's OWN checkbox padding is
 * RESPONSIVE, unlike facet-7's flat 10px - confirmed via the same live
 * baseline-now comparison at all 3 viewports: 0px at desktop (1440,
 * matching this theme's own generic `.wpgb-checkbox` rule already, no
 * fix needed there), but 10px below the same max-width:991px breakpoint
 * the carried 5991.css already uses for this facet's other responsive
 * rules (confirmed at both 768 and 390 widths) - another WPGB per-facet
 * runtime "choices padding" setting, this one itself responsive, not a
 * static value this theme can source from a stylesheet.
 */
@media (max-width: 991px) {
	#-wpgb-facet-6-5991 .wpgb-checkbox {
		padding: 10px;
		box-sizing: border-box;
	}
}

/*
 * [Stage 4.1] Read More / Read Less no-JS fallback (plan §8,
 * interactive-components.csv: "Content FULLY expanded and the toggle
 * link hidden unless html.ksm-js is present"). The carried per-instance
 * CSS (assets/oxygen/post/*.css, e.g. "#-read-more-less-15-3239
 * .oxy-read-more-inner{max-height:913px}") sets a real max-height plus
 * a base ".oxy-read-more-inner{overflow:hidden;max-height:200px}" rule -
 * confirmed these apply REGARDLESS of JS (they were already live and
 * visually clipping content throughout Stage 3, with no JS at all, since
 * this is a plain CSS rule, not something readmore.js injects - readmore-
 * init.js explicitly passes embedCSS:false, so the library itself never
 * adds this). Unclipped here for the no-JS case; assets/js/ksm-sp-
 * readmore.js re-establishes the collapsed state via an INLINE style
 * (higher specificity than any stylesheet rule) the moment it runs, so a
 * JS-capable browser is unaffected by this override.
 *
 * The toggle link itself needs NO extra rule here - the carried CSS
 * already has ".oxy-read-more-link{visibility:hidden}" plus
 * "[data-readmore] + .oxy-read-more-link{visibility:visible}", and the
 * `data-readmore` attribute only ever exists when JS added it, so the
 * toggle is already invisible with no JS, structurally, in every
 * carried per-post CSS file - confirmed by grep across all of them.
 */
html:not(.ksm-js) .oxy-read-more-inner {
	max-height: none !important;
	overflow: visible !important;
}

/*
 * [Stage 4.2] Contact pop-up (Oxy Ultimate off-canvas) no-JS :target
 * fallback. The trigger and close control are now real anchors
 * (template-parts/chrome/contact-popup.php) pointing at/clearing
 * `#-ou_off_canvas-2665-2241` - this mirrors `.ou-panel-active`'s own
 * visual effect (the carried assets/oxygen/post/3650.css rules) so a
 * no-JS visitor gets the exact same open state via the browser's native
 * `:target`. A JS-capable visitor never actually triggers `:target`
 * (assets/js/ksm-sp-contact-popup.js calls preventDefault() on both
 * clicks and manages the same effect via inline styles instead), so
 * these two states never conflict.
 *
 * `!important` on visibility/opacity: confirmed via direct Chrome
 * DevTools Protocol inspection (CSS.getMatchedStylesForNode) that the
 * carried CSS's own `.oxy-ou-off-canvas.ou-panel-active .ou-off-canvas-
 * panel{visibility:visible}` rule - despite genuinely having HIGHER
 * specificity than its own base `{visibility:hidden}` rule, confirmed by
 * direct count - was not reliably winning the cascade on the real page
 * (reproducible, cause not identified). The JS path works around this
 * with inline styles (always win); `!important` is this rule's own
 * equivalent guarantee for the no-JS path, which cannot use inline
 * styles.
 */
#-ou_off_canvas-2665-2241:target .ou-off-canvas-backdrop {
	opacity: 1 !important;
	visibility: visible !important;
}
#-ou_off_canvas-2665-2241:target .ou-off-canvas-panel {
	visibility: visible !important;
}
#-ou_off_canvas-2665-2241:target .ou-off-canvas-panel.ofc-front {
	transform: none !important;
}
/*
 * [Stage 4.2] The panel is full-viewport-width below 992px and a fixed
 * 300px above it, confirmed by live measurement of the baseline at every
 * width from 390 to 1440 (the exact 992px boundary found by bisection) -
 * the carried CSS's own `--panel-width` custom property never changes in
 * any stylesheet this project carries, so this responsive behaviour must
 * come from Oxy Ultimate's own proprietary runtime JS re-setting it -
 * reproduced here as plain CSS (observed OUTPUT only, not their code) so
 * it works identically with or without JS.
 */
@media (max-width: 991px) {
	.oxy-ou-off-canvas {
		--panel-width: 100%;
	}
}

/*
 * [Stage 4.4] The 5991 facet form's own "Apply Filters" submit button is
 * a REQUIRED no-JS fallback (interactive-components.csv's own row for
 * this facet bar, item dd2) - tagged `ksm-nojs-only` at the time it was
 * built, with this exact rule promised as a Stage 4 follow-up. Now that
 * assets/js/ksm-sp-facets.js auto-applies on change, the button is
 * genuinely redundant for a JS-capable visitor and is hidden here,
 * matching plan §8's documented `html.ksm-js` convention already used by
 * every other Stage 4 no-JS fallback in this file.
 */
html.ksm-js .ksm-nojs-only {
	display: none;
}

/*
 * [Stage 4.5] The carried `.top-animate-header` shine sweep
 * (assets/oxygen/universal.css - `animation: 3s linear 0s infinite
 * normal none running textclip`, stage-4/cta-timing.json) is a pure
 * CSS background-clip:text effect, no JS at all - left completely
 * untouched, both instances (header CTA + "FREE QUOTES", only one
 * visible/running per breakpoint per that survey). This is the ONLY
 * change for 4.5: a reduced-motion override stopping the sweep for
 * visitors who've asked for less motion, while the text itself stays
 * exactly as readable - `-webkit-text-fill-color`/`color` and the
 * gradient are left in place (removing them would drop the white
 * fallback colour some browsers rely on), only `animation` is
 * disabled and `background-position` pinned to a static, mid-gradient
 * (readable, non-flickering) value.
 */
@media (prefers-reduced-motion: reduce) {
	.top-animate-header {
		animation: none;
		background-position: 0% center;
	}
}

/*
 * [Stage 4.6] Side pro-menu (single.php's OUR SERVICES sidebar,
 * assets/js/ksm-sp-promenu.js). No-JS fallback: the carried CSS's
 * default `.sub-menu{visibility:hidden;position:absolute}` makes any
 * nested submenu items unreachable (hidden elements are out of the tab
 * order) without the click/keyboard toggle this script adds - so
 * without JS every submenu is forced open and back into normal document
 * flow instead, always reachable, no interaction required. The parent
 * `<a>` itself is untouched either way and still navigates normally.
 */
html:not(.ksm-js) .oxy-pro-menu .menu-item-has-children > .sub-menu {
	visibility: visible !important;
	position: static !important;
	opacity: 1 !important;
}