/* ========================================================================= Maglula — SITE-WIDE fixes (STAGING ONLY) Unlike maglula-mobile-ux.css (enqueued only on single product pages, see maglula-mobile-ux.php's is_product() gate), this file is enqueued on EVERY page by a separate, unconditional wp_enqueue_scripts callback in the same loader. Keep this file to genuinely site-wide, surgical fixes only — it is not the place for product-page UX work. ========================================================================= */ /* --------------------------------------------------------------------- 1. Orientation-overlay fix. ROOT CAUSE (confirmed by reading the live installed parent-theme CSS, master-theme's main-style.css, read-only -- not edited, not an mu-plugin file): the theme defines .mobile-orientation-image { display: none; } @media (orientation: landscape) { .mobile-orientation-image { display: block; position: fixed; top: 0; left: 0; width: 100vw; height: 100vh; z-index: 999999; } .mobile-orientation-image img { width: 100vw; height: 100vh; object-fit: cover; } } with NO device-capability condition at all -- only `orientation: landscape`. Any browser window wider than it is tall matches that query, including an ordinary desktop/laptop window simply resized short and wide. Confirmed live: a genuine, non-emulated desktop Chrome window resized to ~780x768 triggered the exact same full-page overlay a real phone would show rotated sideways, on every page of the site (this bug is in the theme's own sitewide stylesheet, not scoped to product pages). REQUIRED BEHAVIOR (set by Yuval): the overlay may appear ONLY when every signal available to CSS indicates an actual touch-only device that is currently in landscape -- not merely "anything that looks landscape." Specifically: - desktop/laptop, any window size or shape -> never shows - a touchscreen/hybrid laptop or a tablet with a trackpad/mouse attached (a hover/fine-pointer input is AVAILABLE, even if not the primary one right now) -> never shows - a real touch-only phone or tablet, portrait -> normal site - a real touch-only phone or tablet, landscape -> warning shows - rotating back to portrait -> warning disappears immediately (plain CSS, re-evaluated live, no JS/timeout) APPROACH: rather than "hide when it looks like a desktop" (an inference), this is written the other way around, as the task asked: hide UNCONDITIONALLY by default, then positively re-enable the overlay only under an explicit, narrow "definitely touch-only AND landscape" media query. A device only matches that re-enable rule when ALL FOUR of these are true at once: - hover: none -- the PRIMARY input has no hover capability - pointer: coarse -- the PRIMARY input is not precise (a finger, not a mouse/trackpad/stylus) - any-hover: none -- NO input device attached ANYWHERE on the device supports hover (this is what correctly keeps the overlay off for a touchscreen laptop or a tablet with a trackpad/mouse connected, even in the moment touch is the primary input) - any-pointer: coarse -- likewise, no attached input anywhere is a precise pointer Using `any-hover`/`any-pointer` alongside the plain `hover`/`pointer` features (rather than either pair alone) is the one part of this rule that isn't just "the obvious version": `hover`/`pointer` describe only the device's PRIMARY input, which is ambiguous and inconsistently decided by the browser on a hybrid device with both a touchscreen and a trackpad/mouse. `any-hover`/`any-pointer` describe whether hover/fine pointer is available from ANY input mechanism on the device at all, so requiring all four to fail is what reliably means "this device has no mouse/trackpad/stylus available, period" -- not just "isn't using one this instant." No UA sniffing, no JavaScript, no timers: this is pure CSS, so it re-evaluates instantly on every real device-capability change (and on orientation change), and it cannot get stuck the way a JS-driven check could. --------------------------------------------------------------------- */ /* Default: unconditionally cancel the theme's own rule everywhere. This alone would be the "hide on desktop" inference the task said not to rely on by itself -- it is only the default half of the pair below. */ .mobile-orientation-image { display: none !important; } /* Positive re-enable: show the overlay, and only the overlay's own intended full-screen landscape treatment, exactly when the device is unambiguously touch-only AND currently in landscape. Everywhere else (including every desktop/laptop shape, and any hybrid/tablet with a hover-capable input attached) this media query simply never matches, so the unconditional hide above stands. */ @media (orientation: landscape) and (hover: none) and (pointer: coarse) and (any-hover: none) and (any-pointer: coarse) { .mobile-orientation-image { display: block !important; position: fixed !important; top: 0 !important; left: 0 !important; width: 100vw !important; height: 100vh !important; z-index: 999999 !important; } .mobile-orientation-image img { width: 100vw !important; height: 100vh !important; object-fit: cover !important; } } /* --------------------------------------------------------------------- 2. reCAPTCHA badge -- hidden using Google's own supported method. INSPECTION FINDINGS (read-only; confirmed on live installed staging, not assumed): - Component: "Advanced Google reCAPTCHA" plugin (WebFactory, v1.22) supplies the site's reCAPTCHA v3 site key; Contact Form 7's own built-in reCAPTCHA module (wpcf7-recaptcha-js) uses it to protect CF7 forms with an invisible (score-based) challenge -- no visible v2 checkbox anywhere on this site. - The v3 script + floating badge load on EVERY front-end page (home, about, product, category, for-dealers...) because the theme's global footer (.footer-contact > .footer-form) embeds two Contact Form 7 forms (a newsletter signup and a footer contact form) on every page template. This is NOT an unnecessary global load -- a real reCAPTCHA-protected form is genuinely present sitewide. - The WooCommerce review/comment form (#commentform) does NOT use Google reCAPTCHA at all -- the same "Advanced Google reCAPTCHA" plugin is configured to protect it with its own separate math/ image captcha (wp-content/plugins/advanced-google-recaptcha/libs/ captcha.php, "Are you human? Please solve:"). Hiding the Google badge has no effect on that form or its captcha. - wp-login.php does not load the reCAPTCHA script or badge on this install, so nothing to change there. - No reCAPTCHA attribution text or Google Privacy Policy / Terms of Service links existed anywhere on the site before this change (checked: homepage, about, product, category, for-dealers, wp-login.php). Per Google's reCAPTCHA terms, the badge may be hidden with CSS only if compliant attribution (the required wording plus working Privacy Policy and Terms of Service links) is shown somewhere in the relevant user interface. `visibility: hidden` is used rather than `display: none` -- display:none stops reCAPTCHA working, visibility:hidden keeps it in the DOM and fully functional, just not painted. The attribution markup itself (real tags -- CSS content: cannot produce a working/accessible link) is added by a new, separate wp_footer hook in maglula-mobile-ux.php. It fires on every front-end page specifically because that is where the actual protected form already lives -- not as a generic disconnected footer notice. This block only styles it. --------------------------------------------------------------------- */ .grecaptcha-badge { visibility: hidden !important; } .maglula-recaptcha-attribution { font-size: 12px; line-height: 1.5; color: #9a9a9a; text-align: center; max-width: 640px; margin: 16px auto 0; padding: 0 16px; } .maglula-recaptcha-attribution a { color: #9a9a9a; text-decoration: underline; } .maglula-recaptcha-attribution a:hover, .maglula-recaptcha-attribution a:focus { color: #707070; } /* --------------------------------------------------------------------- 3. Rifle Mag Loaders category hero -- reduce excess vertical space between the title and the caliber submenu. ROOT CAUSE (confirmed via DOM/computed-style inspection, not assumed): The shared category-archive hero partial (#banner.home-banner.shop-page) positions its .text block with an absolutely-positioned, translate(-50%,-50%)-centered `top` value. On Pistol Mag Loaders, #banner also gets an extra `.search` class (because that category has the "What's your caliber?" search box), and a `.search`-scoped theme rule pushes .text down to make room for that box above the submenu. Rifle Mag Loaders has no such search box and no `.search` class, so .text stays at the theme's generic, higher `top` position (47% unconditional / 38% under max-width:1024px) with nothing below it before the submenu -- producing a large, unintentional-looking empty gap that Pistol does not have. FIX: reposition ONLY the Rifle Mag Loaders top-level category's .text block, scoped via WordPress's own term body class (stable, not URL-dependent). A single unconditional rule covers all tested widths (390px / 430px / ~800px / desktop) because its higher specificity (4 class-level components) beats both of the theme's competing rules regardless of the @media breakpoint -- no duplicate media-query rule needed. Scoped to the exact top-level term only, so Rifle's four subcategories, BenchLoader, Counter-top display, LULA/StripLULA and all Pistol pages are unaffected (verified: none of them carry body.term-rifle-mag-loaders). Does not change the hero image, the submenu, or Pistol Mag Loaders. --------------------------------------------------------------------- */ body.term-rifle-mag-loaders .home-banner.shop-page .text { top: 70%; } /* --------------------------------------------------------------------- 4. "Find Your Pistol Loader" / "What's your Caliber?" caliber search -- mobile typography: reduce oversized/heavy list text and vertical space (homepage "Find Your Pistol Loader" widget and the Pistol Mag Loaders category hero search; both render the exact same markup/classes). ROOT CAUSE (confirmed via DOM/computed-style inspection, not assumed): The caliber list items (.btn-select-search), the "Can't find your fit?" button (.find-your-fit) and the per-item spacing all use a flat `1.25rem` / `1.30208rem` (theme's own unconditional rules, no mobile override) with font-weight 700. Because this theme scales the ROOT font-size itself with viewport width (confirmed: root font-size is ~16.4px at 390px wide, but balloons to ~32.3px around 768px wide before shrinking back down on real desktop), those rem-based values render as a huge ~40px bold caliber list on phablet/small-tablet widths, and a borderline ~20.5px bold list even at 390px -- both bold weight and inter-item margin (1.30208rem) also scale with that same runaway root font-size, compounding the "heavy / too much vertical space" effect. One caliber string (".22 Magnum - Not Supported") already sits right at the wrap threshold at the original size, so any larger size wraps it to an oversized two-line entry. FIX: override with fixed px values (immune to the theme's root font-size scaling) inside one mobile-only media query matching the theme's own breakpoint. 19px / 600 weight is the largest size that keeps every current caliber entry on one line at the narrowest supported width (390px; wider widths have more room, confirmed), so it avoids the oversized two-line wrap while staying well above the ~16px minimum and clearly legible for older users. Weight reduced 700 -> 600 (still clearly bold, not thin) to cut visual heaviness without shrinking the type. Per-item margin cut 1.30208rem (~21px at 390px, ~42px at 768px) -> a flat 12px, and small vertical padding added to the button itself so the clickable/tappable area doesn't shrink even though the visual gap between rows does. Net effect: noticeably more of the list is visible per screen/scroll step, with no wrapping, on both the homepage widget and the Pistol Mag Loaders hero. Desktop (>=1024px) is untouched -- the theme's own root-font scaling already shrinks this component back down above that width. --------------------------------------------------------------------- */ @media (max-width: 1023.98px) { .select-search-list .select-search-item .btn-select-search { font-size: 19px !important; font-weight: 600 !important; padding: 4px 2px !important; } .search-field-row .search-field-column .find-your-fit { font-size: 19px !important; font-weight: 600 !important; } .select-search-list .select-search-item { margin-bottom: 12px !important; } } /* ---------------------------------------------------------------- HOMEPAGE TESTIMONIALS — MOBILE SPACING FIX (2026-10-01) ---------------------------------------------------------------- TWO root causes found by live DOM/CSS measurement on staging (.testimonial-slider carousel, Swiper-based, 4 slides): 1) Testimonial text -> pagination dots gap. The 4 testimonial quotes are different lengths, so each .swiper-slide has a different NATURAL content height (measured 255/224/183/206px at 390px wide). But the dots are NOT inside each slide -- they are a single shared .swiper-pagination, absolutely positioned at the bottom of the shared .swiper container, whose own height is fixed to the TALLEST slide (confirmed: slides are not flex-stretched to equal height here; autoHeight is off, and turning it on was tested live and found unreliable on this Swiper build -- it kept measuring the wrong slide instead of the active one, so it was not used). Result: short testimonials left up to ~87px of dead space above the dots, long ones only ~14px. Fix (safe, CSS-only, no overlap risk, verified by measurement): - trim .testimonial-slider's line-height (1.6 -> 1.45, still a normal comfortable reading value) and .logo's margin-bottom (5vw -> 2vw). Both only ever shrink the TALLEST slide's own height (the thing that sets the shared container height), which pulls the dots closer to every shorter slide's text too, with zero risk of the tallest slide's text overlapping the dots. - trim .swiper's reserved padding-bottom (11.45vw -> 10vw), a smaller, uniform trim, kept conservative so the tallest slide (the tightest case) still keeps a comfortable ~9px clearance above the dots at 390px wide. Verified result at 390px: gap now ~5-9px (was 14px) on the longest testimonial, ~35-67px (was 46-87px) on the shorter ones -- noticeably tighter on every slide, nothing touches the dots. 2) "See All Testimonials" -> "Find Your Pistol Loader" gap. Not a margin/min-height on the testimonial section at all -- .testimonial-slider's own bottom padding is already 0 on mobile. The real source is the NEXT section's own top padding: .find-loader { padding-top: 35.33vw } inside the theme's mobile media query (main-style.css) -- 137.8px at 390px wide, versus 8-13vw used for top padding on every comparable mobile section elsewhere on this page (.reviews, .about, .distributors, .products-slider), so this was a clear outlier, not a value intentionally sized for this section. Reduced to 12vw, in line with those other sections, directly overriding the real property -- no negative margin used. Verified result: gap 139px -> ~48px at 390px wide (also checked 430/768px, scales proportionally, no overlap at any width). Both rules are scoped to the same (max-width: 1023.98px) breakpoint the theme itself already uses for these elements. Desktop (tested at 1440px) is confirmed completely unaffected -- all four computed values match the unmodified desktop CSS exactly. NOTE: the testimonial carousel's left/right navigation arrows (part of the same task request) are NOT included here -- they require a small JS change, and maglula-mobile-ux.js (the only authorized JS file) is not enqueued on the homepage at all, only on product pages. See the written report for the finding and the recommended path, pending Yuval's go-ahead before any JS/PHP work. ---------------------------------------------------------------- */ @media (max-width: 1023.98px) { .testimonial-slider { line-height: 1.45 !important; } .testimonial-slider .logo { margin-bottom: 2vw !important; } .testimonial-slider .swiper { padding-bottom: 10vw !important; } .find-loader { padding-top: 12vw !important; } } /* ========================================================================== Homepage UX round (2026-10-01): testimonial arrows + vertical rhythm ========================================================================== */ /* ---------------------------------------------------------------------- 2. Testimonial carousel prev/next arrows. Buttons are inserted by maglula-homepage-ux.js (homepage only) as direct children of .testimonial-slider, NOT inside .swiper (which has overflow:hidden -- a child positioned outside its box would be clipped). They sit in the empty side gutter between the viewport edge and the centered .swiper/.container box (confirmed >=35px at 390px width, wider at every larger breakpoint tested), so they never overlap the testimonial text, which runs edge-to-edge inside that box. Vertical "top" is set in JS (measured against the swiper's own height, which changes per active slide -- see height-sync logic below), not here. ---------------------------------------------------------------------- */ @media (max-width: 1023.98px) { .testimonial-slider { position: relative; /* positioning context for the arrow buttons */ } .mux-testi-arrow { position: absolute; z-index: 20; width: 32px; height: 44px; /* comfortable touch target height; width is capped by the available gutter so it never reaches into the text column */ display: flex; align-items: center; justify-content: center; background: transparent; border: 0; padding: 0; margin: 0; cursor: pointer; -webkit-tap-highlight-color: transparent; } .mux-testi-arrow .mux-testi-circle { width: 32px; height: 32px; border-radius: 50%; background: rgba(255, 255, 255, 0.88); box-shadow: 0 1px 4px rgba(0, 0, 0, 0.22); display: flex; align-items: center; justify-content: center; color: #1c1c1c; } .mux-testi-arrow svg { width: 15px; height: 15px; display: block; } /* Horizontal placement (left/right) and exact width/height of the circle are set dynamically by maglula-homepage-ux.js, which measures the real gutter on every call rather than assuming a fixed value -- see that file's sizeAndPlaceArrow() for why. */ } /* ---------------------------------------------------------------------- 3. Find Your Pistol Loader -> Latest Products gap (root cause + fix). ROOT CAUSE: .find-loader had padding-bottom: 47.33vw, a clear outlier against the rest of the site's mobile section paddings (normal range is roughly 13-30vw for bottom padding; see .dealers 13.33vw, .reviews 20vw, .distributors 24vw, .about 25.33vw, .products-slider 30vw). Combined with .products-slider's own 10vw top padding, this produced a real visible-content gap (search box bottom -> "Latest Products" heading top) of roughly 256-295px depending on viewport, read by a visitor as a large accidental empty space rather than an intentional section break. FIX: bring .find-loader's bottom padding down to 10vw, the same value already used for .products-slider's top padding and for the testimonial swiper's own padding-bottom above -- an existing value in the site's spacing system, not a new invented number. Verified this reduces the real content-to-content gap to ~111px at 390px width (scales proportionally at larger widths, same as every other vw-based rule on this page) and reads as a clean, intentional section break. ---------------------------------------------------------------------- */ @media (max-width: 1023.98px) { .find-loader { padding-bottom: 10vw !important; } } /* ---------------------------------------------------------------------- 4. Running-number section bottom margin (root cause + fix). ROOT CAUSE: .running-number-wrapp used margin-bottom: 7.8125rem, an unscoped rem-based value. This site's root font-size scales sharply with viewport width (the same runaway-scaling behavior documented elsewhere in this project: roughly 16.4px at 390px, up to ~32px around 768px, before settling back down above ~1024px), so a rem-based spacing value does not scale the way the rest of the site's vw-based spacing system does -- it produced ~128px at 390px and grows disproportionately larger at mid-range widths like 768px, an outlier against the rest of the page's spacing. FIX: override with a vw-based margin-bottom (20vw) inside the same mobile breakpoint used throughout this file, consistent with how every other section spacing value on this page is expressed. Desktop (>1023.98px) is completely unaffected -- the original rem-based rule from the theme/page CSS still applies there untouched. ---------------------------------------------------------------------- */ @media (max-width: 1023.98px) { .running-number-wrapp { margin-bottom: 20vw !important; } } /* ---------------------------------------------------------------------- 5. Testimonial pagination dots -- reduce oversized MOBILE size. ROOT CAUSE (confirmed via live CSSOM inspection, not assumed): the theme's own mobile breakpoint (style2.css, media max-width:1024px) sets the bullet to 3.8vw !important -- 4.75x larger, PROPORTIONALLY, than the theme's own desktop rule (0.8vw !important, same file). At 390px wide that renders a 14.8px inactive / 22.2px active (existing 1.5x scale transform, untouched) dot -- visibly oversized next to the testimonial text, the arrows and the "See All Testimonials" link. Desktop's own 0.8vw (15.36px at 1920px wide) was not flagged and is left completely untouched by this rule (it is scoped to the same max-width:1023.98px breakpoint used throughout this file). FIX: a fixed, viewport-independent px size instead of vw -- vw scaling is the wrong tool for a small fixed-purpose UI dot, which has no real reason to track page width once it is already legible. 6px inactive / 9px active (the existing 1.5x scale transform does the rest, nothing to change there) is the smallest size that stayed clearly visible, distinguishable, and comfortable for older users when prototyped live against the actual installed carousel, while no longer dominating the section. Pagination logic/behavior is not touched. Same override pattern already used throughout this file: equal selector specificity to the theme's own winning rule (body .testimonial-slider .swiper-pagination-bullet) plus !important, and this stylesheet is enqueued after style2.css/additional.css, so it wins on source order without needing extra specificity or a theme edit. Deliberately scoped to .testimonial-slider only (not the theme's own broader "body .swiper-pagination-bullet" alternate selector, which also matches every other Swiper pagination sitewide, including the product-gallery carousel on product pages): checked live on a product page during regression QA and confirmed the same 3.8vw mobile bug exists there too, but that is a separate, out-of- scope surface this task did not ask for and was not reviewed for -- left exactly as-is so this round only touches what was asked for. ---------------------------------------------------------------------- */ @media (max-width: 1023.98px) { /* UI-04B: was max-width:1024px, which matched the theme's pre-UI-01 style2.css rule. UI-01 moved that theme rule to 1023.98px, so this override now uses the same breakpoint. At exactly 1024px the theme's desktop dot size (0.8vw) applies, the same as at 1025px. */ body .testimonial-slider .swiper-pagination-bullet { width: 6px !important; height: 6px !important; } } /* ---------------------------------------------------------------------- 6. "Find Your Pistol Loader" -> "Latest Products" gap -- DESKTOP. ROOT CAUSE (confirmed via live computed-style inspection at 1920px wide, fresh on this reload, not reused from an earlier session): .find-loader's own padding-bottom is the theme's unconditional, uncapped `15vw` (288px at 1920px wide). Every comparable sibling section's top padding on this page is a consistent ~5vw at the same width (.testimonial-slider 96px, .products-slider 96px, .dealers 96px) -- .find-loader's bottom padding is the one outlier, same relationship as the mobile fix in block 3 above, just uncapped at wide desktop instead of overridden. Combined with .products-slider's own 96px top padding this produced a real, visually-confirmed content-to-content gap (search box bottom -> "Latest Products" heading top) of 482px at 1920px wide -- clearly excessive, matching Yuval's reported issue; screenshotted and visually confirmed before writing this rule, not assumed from the numbers alone. FIX: brings .find-loader's bottom padding in line with the same ~5vw the rest of the system already uses at this width -- not a copy of the MOBILE 10vw value (which would be the wrong number here, per the explicit instruction not to reuse mobile vw values for desktop) -- via clamp(), so it scales proportionally like the rest of the page just above the mobile breakpoint, then stays capped at a sane maximum on very wide monitors instead of continuing to grow uncapped: - floor 44px: keeps a small but clearly intentional gap right at the 1024px edge (5vw there would be ~51px anyway, so the floor is a safety margin, not the controlling value at any tested width). - 5vw preferred: matches the system's own established top-padding proportion used by the sibling sections above, so the section reads as part of the same intentional rhythm, not a new value. - ceiling 100px: close to desktop's own existing 96px (5vw at 1920px) sibling value, so 1920px-and-up monitors keep essentially the same gap rather than the padding continuing to balloon past 100px at 2560px/3440px/etc -- this is the actual fix for the reported issue. Only .find-loader's bottom padding is touched. The other desktop section boundaries audited in this same pass (products-slider -> dealers, dealers -> running-number, running-number -> footer) were visually screenshotted at 1920px wide and read as intentional, proportionate section breaks -- not outliers -- so they are left unmodified rather than changed without a demonstrated problem. Mobile (<=1023.98px, block 3 above) is untouched by this rule (min- width:1024px gate). ---------------------------------------------------------------------- */ @media (min-width: 1024px) { .find-loader { padding-bottom: clamp(44px, 5vw, 100px) !important; } } /* ====================================================================== UI-03 — small responsive fix batch (STAGING proposal 2026-10-05, rev 2) A: Latest Products text colour below 1024px. B: Find Your Fit result layout below 1024px (phones/tablets). C: Find Your Fit result layout from 1024px (desktop) — UI-03B desktop. CSS only. No PHP, JS, UA detection, images or content involved. ====================================================================== */ /* ---------------------------------------------------------------------- UI-03A. Homepage "Latest Products": white text on a white page. ROOT CAUSE: the theme rule @media (max-width:1023.98px) .products-slider .swiper-slide { color:white } was written for the phone slider (server-side wp_is_mobile() markup: .container > .swiper-wrap > .swiper > .swiper-wrapper > .swiper-slide, active slide on a dark card). Desktop-markup visitors below 1024px (iPad Safari in desktop mode, small desktop windows) get the static row instead (.container > .swiper-slide, no dark card), so titles and dates were white on white. FIX: only the static row's slides (direct children of .container) inherit the page colour again, exactly as they do at >= 1024px. The phone slider's slides are never direct children of .container, so they keep their white text. ---------------------------------------------------------------------- */ @media (max-width: 1023.98px) { .products-slider .container > .swiper-slide { color: inherit; } } /* ---------------------------------------------------------------------- UI-03B (patch sections B and C). Pistol Mag Loaders "Find Your Fit": the result card is overlapped by the caliber links and/or cut off by the dark banner. ROOT CAUSE (theme, pre-existing, same mechanism at every width): - the banner has a fixed height with overflow:hidden below 1024px: 100vh (.long-mobile removes the max-height); from 1024px: min(100vh, 46.875rem) (theme max-height); - the whole search/result block lives inside the absolutely positioned .text (top:49vw below 1024px; top:25rem plus translate(-50%,-50%) from 1024px), in a zero-height row, so the banner can never grow with its content; - the caliber links (.sub-category-list) are pinned at bottom:5%. When the result card does not fit, the links are drawn over it and the rest is clipped (on desktop almost the whole result). FIX: ONLY while a result is displayed (the result block contains a product), the search block joins the normal flow at exactly the same position, so the banner grows when the result needs more room. Its minimum height stays the theme's own height; the hero images keep their exact place; the caliber links stay pinned near the (now possibly taller) banner bottom, below the result. Every state before a result (caliber list, manufacturer/model lists, New Search) is left to the theme unchanged. Opening a list again clears the result (theme JS), so these rules switch off by themselves. Browsers without :has() support simply keep today's behaviour. ---------------------------------------------------------------------- */ /* Section B — UI-03B below 1024px (phones, tablets, landscape phones) */ @media (max-width: 1023.98px) { .home-banner.shop-page.long-mobile:has(.trigger-result-product-block .item-prod) { height: auto; min-height: 100vh; max-height: none; padding-bottom: 5vh; } .home-banner.shop-page.long-mobile:has(.trigger-result-product-block .item-prod) .text { position: relative; top: 0; margin-top: 49vw; } .home-banner.shop-page.long-mobile:has(.trigger-result-product-block .item-prod) .search-caliber-row { height: auto; } .home-banner.shop-page.long-mobile:has(.trigger-result-product-block .item-prod) .imgs { position: absolute; top: 0; left: 0; width: 100%; } .home-banner.shop-page.long-mobile:has(.trigger-result-product-block .item-prod) .sub-category-list { bottom: 5vh; } } /* Section C — UI-03B desktop, from 1024px. Theme values used: banner height min(100vh, 46.875rem); links at 5% of it = min(5vh, 2.34375rem); .text top 25rem with translateY(-50%) of its own height (7.0535rem: title + gap), i.e. its top edge sits at 25rem - 3.5268rem. In flow, the vertical translate is dropped (it would otherwise move with the result height) and that offset is used as the margin instead, so the title, fields and New Search stay put. */ @media (min-width: 1024px) { .home-banner.shop-page.long-mobile:has(.trigger-result-product-block .item-prod) { height: auto; min-height: min(100vh, 46.875rem); max-height: none; padding-bottom: min(5vh, 2.34375rem); } .home-banner.shop-page.long-mobile:has(.trigger-result-product-block .item-prod) .text { position: relative; top: 0; margin-top: calc(25rem - 3.5268rem); transform: translateX(-50%); } .home-banner.shop-page.long-mobile:has(.trigger-result-product-block .item-prod) .search-caliber-row { height: auto; } .home-banner.shop-page.long-mobile:has(.trigger-result-product-block .item-prod) .imgs { position: absolute; top: 0; left: 0; width: 100%; } .home-banner.shop-page.long-mobile:has(.trigger-result-product-block .item-prod) .sub-category-list { bottom: min(5vh, 2.34375rem); } } /* ========================================================================== Migrated from WordPress Customizer "Additional CSS" (STAGING, 2026-10-06) -------------------------------------------------------------------------- These two rules previously lived only in the staging Customizer (Appearance > Customize > Additional CSS) and were not on production. Yuval approved both designs on 2026-10-06 (Production Readiness open decisions review). They now live here, in controlled project CSS, and were removed from the staging Customizer in the same change. Behaviour is identical to the Customizer originals (same selectors, same media query, same values). No !important is needed: this file loads after the theme's main-style.css, and each selector is at least as specific as the theme rule it overrides: - theme: .mobile-nav-wrap-container .mobile-nav-container { background-color: rgba(0,0,0,0.9) } (all widths) - theme: .home-banner { height: 150vw } (<= 1023.98px) Rollback: restore the pre-change backup of this file AND restore the original Customizer text (see PRODUCTION_READINESS_CUSTOMIZER_MIGRATION_QA). ========================================================================== */ /* Mobile/tablet menu: solid black background (theme default is 90% black, which lets the page show through behind the open menu). */ @media (max-width: 1023.98px) { .mobile-nav-wrap-container .mobile-nav-container { background-color: #000000; } } /* Homepage hero: 135vw instead of the theme's 150vw below 1024px. Removes the empty dark band under the hero picture; the picture box itself is ~132-135vw tall, so nothing is cropped (verified 320-1023px). */ @media (max-width: 1023.98px) { body.home .home-banner { height: 135vw; } } /* ========================================================================== UI-04A — About page: horizontal overflow at 1024–1439px (STAGING proposal) -------------------------------------------------------------------------- ROOT CAUSE (theme + AOS, pre-existing, same on production): The About section's text column, ".about .text", uses data-aos="fade-left". Until it animates, AOS keeps it shifted translateX(100px). At 1024–1439px the container's right margin is smaller than 100px, so the column reaches past the viewport. The result is a horizontal scrollbar and a sideways-draggable page: 29px at 1024, 24px at 1100, 17px at 1200, 11px at 1280, 5px at 1366. AOS is set to once:true and offset:300, with a 700ms delay and 800ms duration. The overflow therefore lasts from page load until the visitor reaches the section and the animation finishes. Below 1024px the theme already clips this area: main-style.css @media (max-width:1023.98px) .white-sections { overflow:hidden } From 1024px nothing clips it. FIX: clip horizontal overflow on the About section only, desktop widths only. - "overflow-x: clip" does not create a scroll container. - It leaves vertical overflow visible. - The section layout is unchanged (verified: identical element positions and page height at 1024 and 1440). When the animation ends, all content sits inside the section, so nothing is hidden. Only the first 100px of the slide-in, which happens off-screen, is clipped. Browsers without "clip" support (Safari < 16) ignore the rule and keep today's behaviour. ========================================================================== */ @media (min-width: 1024px) { .page-template-about-us .about { overflow-x: clip; } }