/* ========================================================================== Mouldshop skin for VENDOR Swift's product slider — TASK-0017, product-slider half. WHAT CHANGED AND WHY THE FILE WAS RENAMED. This replaces the bespoke `mouldshop-product-slider.css`, which skinned our own `MouldshopProductSlider.cshtml` and its `.ms-pcard` markup. Both are deleted. The slider is now vendor Swift's `Swift-v2_ProductComponentSlider`, configured through its own 28-field admin panel, and its cards are vendor product-list components rendered from the "Product List Card" page (5861) — so there is no Mouldshop card markup left to style. The rename exists so the record cannot be misread as "the old skin survived". SCOPE OF THIS FILE: the slider CONTAINER only. Card internals are vendor components and are deliberately left alone — invariant 3, and the M4 halt-bar forbids editing vendor templates in place. Everything below is scoped to `#ComponentSliderProducts_* ` / the paragraph's own `[id^="ComponentSliderProducts_"]` AJAX target so no other Swift slider on the site is touched. That container, not the paragraph form, is the slider's parent — the form is its SIBLING, which is why a `.item_swift-v2_productcomponentslider` descendant selector silently matched nothing. THREE REFERENCE CLASSES ARE NOT REACHABLE ON SWIFT v2.3.0, and they are NOT faked here. The reference renders `slider-item-nogap slider-nav-autoplay slider-nav-animation`. On this box `eCom/ProductCatalog/ProductSliderComponent.cshtml` computes all three into local variables (lines 54, 67-69) and then omits them from the class attribute — and the corresponding fields are absent from the item type. Adding them from CSS is impossible for two of the three (`slider-nav-autoplay` and `slider-nav-animation` are read by the swiffy JS, not by CSS), and faking the third alone would produce a half-match that reads as a bug. They are NAMED in the WORKLOG instead, which is what the packet asks for. Do not "fix" this with a JS class injection. ========================================================================== */ /* SIDE PADDING - NONE AT ANY WIDTH since 2026-09-24 (see the note below the rule). It began MOBILE-ONLY (operator, 2026-09-04: "slider - except mobile - remove side paddings"). Above 990 the row runs to the container edge; below it the 1.25rem is kept, because on a narrow screen the cards would otherwise touch the viewport edge with nothing to separate them from it. 990 is the project breakpoint where the layout goes single-column and the nav switches, so "mobile" means the same thing here as everywhere else in this build rather than being a number invented for this rule. The block values are NOT set here any more — the lift and the shadow room own them, in mouldshop-card-surfaces.css 2a/2e. Declaring the shorthand would silently take them back, so this is `padding-inline` only. */ [id^="ComponentSliderProducts_"] { /* NO CAP OF ITS OWN (operator, 2026-09-24, DevTools on this rule: "you missed max-width"). It was var(--ms-page-width), which below 1080 is calc(100% - 2rem) - resolved against THIS box's parent, so it took another 16px off each side inside a row container that is already capped. The row container ([data-swift-container]) is the one width authority, as for the hero and the info stripe. */ max-width: none; margin: 0 auto; padding-inline: 0; } /* NO MOBILE PADDING EITHER (operator, 2026-09-24: "why slider has different size then other components like hero or info slider?" - then "go"). The 1.25rem below 990 (kept on 2026-09-04 so the cards would not touch the viewport edge) is removed: the row now spans the same box as the hero and the info stripe at every width. What remains inside is the track's half gutter (mouldshop-card-surfaces.css 2a), which holds the row's own end dividers. Sliders with their nav OUTSIDE still get 1.25rem from the rule below, for their chevrons. */ /* THE CHEVRONS NEED THE ROOM THE ROW GAVE UP — but only where they sit OUTSIDE the track. Swiffy has two nav placements. `slider-nav-on-slides` puts the buttons over the cards, and the home slider — the one the operator was looking at — uses it. WITHOUT that class the buttons sit ENTIRELY outside the track, a full button-width beyond its edge: measured `left: 1168px` against a 1120px wrapper. The wrapper's 1.25rem was what kept them on screen, and removing it put 16px of button past the viewport on the PDP at 1199 and 1100 — a real horizontal overflow, measured, not a near miss. INSETTING THE TRACK INSTEAD OF THE ROW DOES NOT WORK, and it is worth writing down: the `.swiffy-slider` wrapper is a `g-col-12` GRID ITEM, so `margin-inline` shifted it right without shrinking it and pushed the button further out — overflow 16px became 36px. The room has to come from the component's padding, which is what it always was. So the padding returns, scoped to the placement that needs it rather than to a page or an id: sliders whose nav is on-slides keep the edge-to-edge row the operator asked for, and sliders whose nav is outside keep their buttons. */ [id^="ComponentSliderProducts_"]:has(.swiffy-slider:not(.slider-nav-on-slides)) { padding-inline: 1.25rem; } /* Swiffy paints its own nav; give it Mouldshop's palette rather than Bootstrap's defaults. */ [id^="ComponentSliderProducts_"] .swiffy-slider { --swiffy-slider-nav-light: #ffffff; --swiffy-slider-nav-dark: var(--ms-navy, #0A2979); --swiffy-slider-track-height: 0; } [id^="ComponentSliderProducts_"] .slider-nav { color: var(--ms-ink); transition: opacity .2s ease, transform .2s ease; } [id^="ComponentSliderProducts_"] .slider-nav:hover { transform: scale(1.06); } /* Card frame. The card body itself is vendor markup; this is the tile around it. */ [id^="ComponentSliderProducts_"] .slider-container > li { background: #fff; border: 1px solid var(--ms-border, #e6e9f0); border-radius: 12px; overflow: hidden; transition: box-shadow .18s ease, transform .18s ease, border-color .18s ease; } [id^="ComponentSliderProducts_"] .slider-container > li:hover { box-shadow: 0 12px 28px rgba(10, 41, 121, .12); border-color: var(--ms-blue, #6CB2DE); transform: translateY(-2px); } /* Product name and price — Mouldshop type, vendor elements. */ [id^="ComponentSliderProducts_"] .slider-container h3, [id^="ComponentSliderProducts_"] .slider-container .h6 { font-family: var(--ms-font-head, "Montserrat", sans-serif); color: var(--ms-ink); } [id^="ComponentSliderProducts_"] .text-price { color: var(--ms-ink); } /* ========================================================================== INDICATORS — TASK-0101 items 1 and 3. Paired with mouldshop-slider-indicators.js, which owns the COUNT; this file owns only where the strip sits and whether it draws. ========================================================================== */ /* Operator, 2026-09-22: "slider-indicators - has bottom: 0 , I need to increas to 20px". Taken literally, on the property he named. Swiffy also puts `margin-bottom: 1rem` on the same element and that is left exactly as it is — moving two properties when one was asked for would make the next reading of this rule ambiguous. Specificity 0,2,0 against vendor's 0,1,0, so order between the two sheets does not matter here. */ [id^="ComponentSliderProducts_"] .slider-indicators { bottom: 20px; } /* ONE PAGE MEANS NO DOTS. Set by the JS, never authored into the markup — the count is a measurement and it changes with the viewport, so the markup cannot know it. The attribute rather than a class purely for specificity arithmetic: this selector is 0,3,0 and the strongest `display` rule vendor has for this element is `.slider-indicators-sm .slider-indicators` at 0,2,0. It wins at every breakpoint without `!important`, so a later rule of ours can still override it in the normal way. */ [id^="ComponentSliderProducts_"] .slider-indicators[data-ms-indicators="hidden"] { display: none; } /* AND NO EMPTY BAND WHERE THEY WERE. `slider-indicators-outside` reserves height on the slider root for a strip that is drawn below the track; with the strip gone that padding is a gap nobody asked for. Only `slider_20201`, the vendor PDP template's slider, carries that class today — this rule is here so hiding the dots is complete wherever it is set, not because that page is in scope. */ [id^="ComponentSliderProducts_"] .swiffy-slider:has(.slider-indicators[data-ms-indicators="hidden"]) { padding-bottom: 0; } /* -------------------------------------------------------------------------- SLIDER TITLE (TASK-0112). The paragraph's own Title field, which vendor v2.3.0 stores and never renders; our shadow of Paragraph/Swift-v2_ProductComponentSlider prints it as h2.ms-slider-title directly before #ComponentSliderProducts_*. It takes the SLIDER's box - same max-width, same centring, same inline padding, including the one case where that padding is 0 (desktop, arrows on the slides) - so the title's left edge sits on the first card's left edge. Type: the display face at the weight the rest of our headings use; colour inherits the row's scheme (DEC-0063). No home slider has a Title today, so this is the first slider title on the site - the style is a proposal for the smoke, not a match. -------------------------------------------------------------------------- */ /* Operator, 2026-09-24: "title has to be centered and no bottom padding". The title is part of the slider COMPONENT (the paragraph's own Title field, printed by our shadow of the vendor paragraph template), so every product slider that has a Title shows it - reuse needs nothing more than filling the field. */ .ms-slider-title { max-width: var(--ms-page-width, 1200px); margin: 0 auto; padding-block: 0; padding-inline: 1.25rem; text-align: center; font-family: var(--ms-font-head, var(--ms-font-display, system-ui, sans-serif)); font-size: clamp(1.25rem, 2vw, 1.5rem); font-weight: 700; line-height: 1.2; color: inherit; } @media (min-width: 990px) { .ms-slider-title:has(+ [id^="ComponentSliderProducts_"] .swiffy-slider.slider-nav-on-slides) { padding-inline: 0; } } /* NO PRODUCTS, NO TITLE (operator, 2026-09-24: PDP slider switched to "Frequently bought", title shown over nothing). The slider is filled by an async request; when it returns no products the container stays without a .swiffy-slider, and vendor's own "hide the column" line looks for a [data-col-size] ancestor our rows do not have. So the title is hidden until - and unless - a slider has actually rendered beside it. That also stops the title flashing on its own while the request is in flight. */ .ms-slider-title:has(+ [id^="ComponentSliderProducts_"]:not(:has(.swiffy-slider))) { display: none; } /* CARDS PER VIEW BELOW 992 — 3 / 2 / 1 (operator, 2026-09-24: "go", on the proposal 4 / 3 / 2 / 1 at 992 / 768 / 576). Vendor swiffy-slider.css sets `--swiffy-slider-item-count: 1` on every .swiffy-slider below 62rem, so the row went straight from 4 cards to one wide card. The steps below are the listing grid's own (mouldshop-card-surfaces.css 1b), so a card is the same width in a slider as in the grid beside it. >= 992 is untouched: the admin SliderLayout (4) still decides there. Swiffy derives --swiffy-slider-item-width from the count, and the dots and autoplay measure the live track, so nothing else needs to know. */ @media (min-width: 768px) and (max-width: 991.98px) { [id^="ComponentSliderProducts_"] .swiffy-slider { --swiffy-slider-item-count: 3; } } @media (min-width: 576px) and (max-width: 767.98px) { [id^="ComponentSliderProducts_"] .swiffy-slider { --swiffy-slider-item-count: 2; } } /* DOTS ON THE 3- AND 2-CARD STEPS, NOT ON PHONES (operator, 2026-09-24: "indicator disappeared on 3?" then "but we dont want this on mobile"). Vendor swiffy hides .slider-indicators below 62rem unless the paragraph ticks "Indicators visible on small devices", which would also show them on the 1-card phone step. So: shown 576-991 by this rule, still hidden below 576 by vendor. 0,2,0 - the one-page rule above (0,3,0) still wins, so a single page still has no dots. */ @media (min-width: 576px) and (max-width: 991.98px) { [id^="ComponentSliderProducts_"] .slider-indicators { display: flex; } }