/** Shopify CDN: Minification failed Line 765:10 Expected ":" Line 769:101 Unterminated string token Line 770:95 Unterminated string token **/ /* CUSTOM_WEIGHTDESIGNER_BY_CLAUDE — weight-designer-kb.css * ========================================================================== * 3D Weight Designer Help & Guide. Sits directly below the WD embed on the * same full-bleed #000F1C surface (same box-shadow/clip-path technique), so * the page reads as one continuous dark canvas. Accent + column mirror the * .wd-embed-help band this section replaces (60×3px #4DA3FF bar, centered * 900px column). Everything scoped .wd-kb / .wd-kb__* — nothing leaks. * * Progressive enhancement contract with weight-designer-kb.js: * no JS → no .wd-kb--js on the root → answers expanded, tabs/search hidden * JS → .wd-kb--js → accordions collapse, tabs + search light up * ========================================================================== */ /* CONTAINED, NOT FULL-BLEED (Ryan 2026-08-02): *"the far left and right edges should be white… similar to so many sections on product pages where you can toggle a box that has sections go full width or not… It'll match the box width on the 'Custom Q&A' section."* So this is the Q&A card's box, to the character: `custom-q-and-a.liquid` → `.ai-faq-accordion__inner-*` is `max-width: calc(var(--page-width, 1320px) + var(--gutter) * 2)` + auto side margins. It is also the SAME formula `.wd-frame` uses for the designer window and `.wd-embed-seo__inner` used for the intro band, so the dark FAQ box now lines up with the canvas edge above it rather than merely being narrower than the viewport. ⚠ THE FULL-BLEED MACHINERY IS GONE ON PURPOSE — do not reinstate `width: 100vw` + negative half-gutter margins to "fix" the white edges; they ARE the request. Kept from the old comment, because it is still the rule for anything on this page that DOES need to bleed: never use `box-shadow: 0 0 0 100vmax` + `clip-path: inset(0 -100vmax)` here. That pair asks the compositor for a ~1000px-spread shadow around a 1,400px-tall section and clips it back, and the designer above RESIZES as it boots (the 3D canvas sizes itself), so a refresh landing mid-restore leaves the stale band behind — Ryan, 2026-08-01: *"the dividing line partially overlapping the top editor section… it covers the entire window and I can't scroll up to it."* `clip-path` also makes the element a containing block for `position: fixed` descendants (the trap that hid the resume dialog — see ui/gate.js). ⚠ NO `border-top` (removed 2026-08-02, Ryan): it was a 1px rgba(255,255,255,.08) hairline that read as a grey rule separating the designer from the FAQ. With the box now inset, the change in width is the separation. */ .wd-kb { background: #000F1C; position: relative; /* WHITE BESIDE THE BOX, AT EVERY WIDTH (Ryan 2026-08-05: *"there needs to be a minimum white padding/margin/gap on the left and right sides of this section, same as what is built into the custom q&a section found on collection pages and product pages… narrow displays maintain some space on the left and right side of the Q&A on that Spirit collection page, but narrow displays don't require a minimum padding/margin on the WD public page"*). ⚠ THE MAX-WIDTH WAS NEVER THE GUTTER — it only LOOKED like one. `max-width` + `margin: auto` produces white beside the box exactly when the viewport EXCEEDS the cap; below it the box takes the full 100% and runs edge to edge. So the wide desktop looked correct and every narrower display lost the gap, which is why this read as a mobile-only fault when it is really "the cap is not doing the job everyone assumed it was". THE Q&A DOES IT WITH `.container` (`sections/custom-q-and-a.liquid` wraps its card in one): the SAME `max-width` as this line, PLUS `padding: 0 var(--gutter)` (assets/main.css). The padding is the part that survives below the cap, and the part this rule was missing. ⛔ BUT IT CANNOT BE PADDING HERE, and that is the one thing to get right. `.container` carries no background — the card inside it does — so its padding shows the page white through. This element IS the dark box (`background: #000F1C`), so padding would simply make the dark wider and produce no gap at all. The gutter has to come off the element's own WIDTH, which is the same reasoning the `margin-top` below is written up for: the box's background must not extend into the gap. `--gutter` is the theme's own responsive gutter (20px / 32px / 80px by breakpoint, assets/main.css) and carries units at every tier — unlike `--section-gap`, see the ⛔ below — so this matches the Q&A's inset breakpoint for breakpoint rather than inventing a number. `margin` stays `auto` so the box still centres once the cap binds on wide screens. */ width: calc(100% - var(--gutter, 32px) * 2); max-width: calc(var(--page-width, 1320px) + var(--gutter, 32px) * 2); margin-left: auto; margin-right: auto; /* WHITE ABOVE THE BOX (Ryan 2026-08-02: *"there should be white margin/padding along the top edge of the FAQ section too"*). `margin`, not padding — the box's own background must NOT extend into this gap, which is the whole point. `--section-gap` is the theme's own between-sections rhythm (48px on live), so this matches the spacing every other section pair on the site uses rather than being a number invented here. ⚠ This gap USED TO BE what makes the designer's lower dark band visible. Measured on Live before it existed: dark above the designer 20px, dark below 20px — already equal — but the lower one ran straight into this box (also #000F1C) with a 0px seam, so it never read as a band and the top looked thicker. Nothing about the designer was asymmetric; the boundary was missing. ⚠ NO LONGER THIS BOX'S JOB (2026-08-10). Ryan moved "Why Design Your Weights with Blue Sky" between the designer and this section, so `.ecore-why` (#F9F9F9) now provides that boundary and this margin is plain section rhythm again. Keep it — the gap is still wanted above a dark full-bleed box sitting under a light one — but do not reason about the designer's band from here, because this element is no longer adjacent to it. ⛔ `--section-gap` IS UNITLESS. theme.liquid emits `--section-gap: {{ settings.section_gap }}` → literally `48`, and every consumer in main.css multiplies it by `--fluid-1-5` (which carries the unit) rather than using it directly. So `margin-top: var(--section-gap, 48px)` resolves to `margin-top: 48`, an invalid declaration that the browser drops **silently** — the push succeeded, the rule was in the served CSS, and the measured gap was still 0px. Only a measurement caught it. The plain `48px` below is a fallback that stands if the calc is ever invalid; the calc wins when it parses, and is the same fluid rhythm every other section pair on the site uses. */ margin-top: calc(48px + var(--wd-kb-mt-extra, 0px)); margin-top: calc(var(--section-gap) * var(--fluid-1-5) + var(--wd-kb-mt-extra, 0px)); /* WHITE BELOW THE BOX (Ryan 2026-08-13: *"what I want on the Help Guide is bottom white padding that can be added… below the card, or top"*). MARGIN for the same reason every other gap here is: this element IS the dark box, so padding can only ever make the dark taller and would produce no white at all. Editor-controlled and defaulting to 0, so a section saved before the setting existed renders exactly as it did. The top counterpart ADDS to the section rhythm above rather than replacing it — otherwise dialling it to 0 would close a gap that was never the editor's to close. Both terms of that calc carry units; see the ⛔ above for why that matters with --section-gap. */ margin-bottom: var(--wd-kb-mb, 0px); /* Editor-controlled (sections/weight-designer-kb.liquid emits the vars). The rem fallbacks are the values this rule shipped with, so a section saved before the settings existed — or any other consumer of this stylesheet — renders exactly as it did. */ padding: var(--wd-kb-pt, 3rem) 0 var(--wd-kb-pb, 4.5rem); font-family: Montserrat, sans-serif; color: rgba(255, 255, 255, 0.85); } .wd-kb__container { max-width: 900px; margin: 0 auto; padding: 0 20px; } /* ── header (matches the retired .wd-embed-help band) ── */ /* `padding-top: 27px` REPLACES the removed accent bar's own footprint (3px rule + its 24px margin-bottom), so dropping the mark leaves the gap rather than pulling the heading up by 27px. Ryan asked to "remove it and just leave it as a gap here" — this is that gap. ⚠ The `.wd-kb__accent` rule is deleted, not just unused: leaving dead CSS for an element the markup no longer emits is how a future session "restores" a thing that was deliberately cut. */ .wd-kb__header { text-align: center; margin-bottom: 28px; padding-top: 27px; } .wd-kb__heading { color: #fff; margin: 0 0 12px; font-size: 28px; font-weight: 700; line-height: 1.2; } /* The two halves of a colon-separated heading. Inline on desktop — one line, as written. The mobile rule that splits them lives in the max-width:749px block. */ .wd-kb__heading-a, .wd-kb__heading-b { display: inline; } .wd-kb__subheading { color: rgba(255, 255, 255, 0.85); margin: 0 auto; max-width: 560px; font-size: 16px; line-height: 1.6; } /* ── search ── */ .wd-kb__search { position: relative; max-width: 560px; margin: 0 auto 10px; } .wd-kb__search-icon { position: absolute; left: 16px; top: 50%; transform: translateY(-50%); color: rgba(255, 255, 255, 0.45); pointer-events: none; } .wd-kb__search-input { width: 100%; padding: 13px 44px 13px 46px; background: rgba(255, 255, 255, 0.06); border: 1px solid rgba(255, 255, 255, 0.14); border-radius: 999px; color: #fff; font: 400 15px/1.4 Montserrat, sans-serif; outline: none; transition: border-color 0.15s ease, background 0.15s ease; -webkit-appearance: none; appearance: none; } .wd-kb__search-input::placeholder { color: rgba(255, 255, 255, 0.4); } .wd-kb__search-input:focus { border-color: #4DA3FF; background: rgba(255, 255, 255, 0.09); } .wd-kb__search-input::-webkit-search-cancel-button { display: none; } .wd-kb__search-clear { position: absolute; right: 10px; top: 50%; transform: translateY(-50%); width: 28px; height: 28px; border-radius: 50%; border: 0; background: rgba(255, 255, 255, 0.12); color: #fff; font-size: 16px; line-height: 1; cursor: pointer; } .wd-kb__search-clear:hover { background: rgba(255, 255, 255, 0.22); } /* ⛔ THE COUNT HOLDS ITS LINE WHETHER OR NOT IT SAYS ANYTHING. It only has text while searching, so hiding it when empty made every search state 26px taller than every browse state — a jump that survived all the paging work because it fires on typing rather than on a page turn, and only ever in one direction. weight-designer-kb.js un-hides it once on init and empties the TEXT instead; the attribute stays in the markup so a JS-off visitor, who has no search box either, never sees a blank reserved line. */ .wd-kb__result-count { text-align: center; margin: 0 0 6px; min-height: 19px; font-size: 13px; color: rgba(255, 255, 255, 0.55); } /* ══ THE RAIL ═══════════════════════════════════════════════════════════════ Ryan, 2026-08-13: *"The pills at the top. I don't like the color choice and how they're kind of randomly scattered."* They were ten labels of ten widths in `flex-wrap: wrap; justify-content: center`, so they broke into ragged centred rows that re-broke at every viewport — and carried three competing treatments at once (a light #E6EBF2 fill against the navy, a blue wipe on hover, a white ring with a bloom when active), which made the navigation the loudest thing in the section. They are now a quiet vertical rail BESIDE the answers: one column, uniform width, a count on each row, and the active row marked by a soft wash and a 3px edge. Nothing wipes, nothing glows. ⚠ THE TWO-COLUMN GRID IS GATED ON .wd-kb--js, like everything else here. Without JS the tabs are display:none and the body must stay a plain block, or the answers would render in a 1fr column beside an empty 194px gutter. 📌 The old `.wd-kind-chip` wipe this replaced still lives in the WD bundle (app/src/styles/weight-designer.css) where the buyer first meets it on the welcome screen. That copy is untouched and still correct there — this was a deliberate port, and un-porting it is not a reason to change the original. */ .wd-kb__tabs { display: none; } .wd-kb--js .wd-kb__body { display: grid; grid-template-columns: 194px 1fr; /* ⚠ ROW GAP MUST BE ZERO. The pager became a grid ROW of its own (see below), and a 38px row gap would stack on top of its existing 18px margin-top and shove it down. The column gap is the one that was ever wanted here. */ column-gap: 38px; row-gap: 0; align-items: start; margin-top: 18px; } /* ⛔ THE RAIL STOPS AT THE BOTTOM OF THE QUESTION FRAME, NOT THE PAGER (Ryan 2026-08-14). A sticky grid item travels within its GRID AREA, and `.wd-kb__panels` was a single grid item holding BOTH the viewport and the pager — so the row measured 763px where the question frame is 692, and the rail overran the last question by exactly the pager's 53px plus its 18px margin. `display: contents` dissolves that wrapper's box so the viewport and the pager become grid items in their own right, on two rows. The rail then shares row 1 with the viewport alone and comes to rest level with the bottom of the tenth question. ⚠ Safe only because NOTHING styles or measures `.wd-kb__panels` — checked, it has no rules in this file and no reference in weight-designer-kb.js. It stays in the DOM for selector matching; only its box goes away. If it ever gains a background, a border or a measured height, this stops being free and the pager has to move in the generated snippet instead. */ .wd-kb--js .wd-kb__panels { display: contents; } .wd-kb--js .wd-kb__tabs { grid-column: 1; grid-row: 1; } .wd-kb--js .wd-kb__viewport { grid-column: 2; grid-row: 1; } .wd-kb--js .wd-kb__pager { grid-column: 2; grid-row: 2; } /* THE RAIL FOLLOWS YOU DOWN (Ryan 2026-08-13: *"The left-side pane with the categories doesn't slide down as you scroll down"*). ⚠ `--header-end-padded` is the THEME'S OWN sticky offset, written in px by main.js `setHeaderEnd()` on every scroll and already used by the product page, the cart summary and featured collections. Use it rather than inventing a number: the header collapses and re-expands as you scroll, so any constant is wrong at one end or the other. Unlike `--section-gap` it carries its unit, so `var()` here is safe — see the ⛔ on `margin-top` above for the one that doesn't and dies silently. ⚠ A sticky GRID ITEM travels within its grid AREA, not its own box, so `align-items: start` on .wd-kb__body does not pin it — the area is as tall as the answers column beside it, which is exactly the distance it should cover. ⛔ ANY ancestor with `overflow: hidden` would kill this outright. .wd-kb and .wd-kb__container deliberately have none (the full-bleed box-shadow/clip-path machinery was removed 2026-08-02 and must not come back); the frame's own clip is on .wd-kb__viewport, a SIBLING, which is why the page turn can clip without breaking this. The max-height is the guard for a short window: a rail taller than the space under the header would otherwise have its last categories unreachable. */ .wd-kb--js .wd-kb__tabs { display: flex; flex-direction: column; gap: 2px; /* ⛔ THE RAIL STOPS LEVEL WITH THE LAST QUESTION, AND THIS MARGIN IS WHAT STOPS IT. Putting the pager on its own grid row (see .wd-kb__panels above) was necessary but NOT sufficient: Chrome constrains a sticky grid item to the grid CONTAINER, not to its grid area, so the rail still travelled the full two-row height and came to rest against the pager — measured 67px past the question frame with the row placement provably correct (grid-template-rows: 700px 70.5px, tabs in row 1). A sticky box IS inset by its own margins, which is the one lever that reliably shortens the travel. ⚠ The value is the pager row's height and is written by the JS (`--wd-kb-rail-tail`), not hardcoded — 70.5px today is the pager's border, padding and button metrics added up, and any restyle of those would silently put the rail back over the pager. Falls back to 0 so a JS-less render is simply unchanged. */ margin: 0 0 var(--wd-kb-rail-tail, 0px); position: sticky; top: var(--header-end-padded, 48px); max-height: calc(100vh - var(--header-end-padded, 48px) - 24px); overflow-y: auto; overscroll-behavior: contain; scrollbar-width: thin; scrollbar-color: rgba(255, 255, 255, 0.18) transparent; } /* A rail row. The accent edge is an INSET box-shadow rather than a border-left, so arriving at the active state costs no layout — a 3px border would shove the label 3px right on every selection. */ .wd-kb__tab { display: flex; align-items: center; justify-content: space-between; gap: 10px; width: 100%; text-align: left; border: 0; border-radius: 8px; padding: 9px 11px; background: transparent; color: rgba(255, 255, 255, 0.60); font: 600 13px/1.35 Montserrat, sans-serif; cursor: pointer; box-shadow: inset 3px 0 0 0 transparent; transition: background 0.16s ease, color 0.16s ease, box-shadow 0.16s ease; } .wd-kb__tab-n { flex: 0 0 auto; font-size: 11.5px; font-weight: 600; color: rgba(255, 255, 255, 0.32); font-variant-numeric: tabular-nums; } /* Bare `hover: hover` — NEVER `and (pointer: fine)`: Ryan's desktop is a touch laptop and reports a coarse pointer. The label's hover lives in here too, not outside: a touch browser holds :hover on the last-tapped element, so an ungated text rule keeps the label lit after the background has already reverted. */ @media (hover: hover) { .wd-kb__tab:hover { background: rgba(255, 255, 255, 0.055); color: rgba(255, 255, 255, 0.9); } } .wd-kb__tab--active { background: rgba(77, 163, 255, 0.13); color: #fff; box-shadow: inset 3px 0 0 0 #4DA3FF; } .wd-kb__tab--active .wd-kb__tab-n { color: rgba(255, 255, 255, 0.6); } /* "All" is a different KIND of choice from the nine categories — it is the whole corpus, not one of them — so a hairline separates it rather than leaving it as the first of ten identical rows. */ .wd-kb--js .wd-kb__tab[data-category="all"] { margin-bottom: 8px; padding-bottom: 13px; border-bottom: 1px solid rgba(255, 255, 255, 0.10); border-radius: 8px 8px 0 0; } .wd-kb__tab:focus-visible, .wd-kb__q-btn:focus-visible, .wd-kb__search-input:focus-visible, .wd-kb__search-clear:focus-visible { outline: 2px solid #4DA3FF; outline-offset: 2px; } /* ══ THE FRAME, THE FLOOR, AND THE PAGE TURN ════════════════════════════════ Ryan, 2026-08-13: *"How big it is. When you click on a pill like 'All', the questions go down 4 pages long."* — 114 collapsed rows plus nine headings is about seven screens. The answer is not a smaller list, it is TEN AT A TIME with a pager, which also keeps every category at one height. ⛔ EVERY RULE BELOW IS A HEIGHT DECISION, and each one exists because a version without it visibly moved the Next button under the cursor. The three causes found by walking every page of every category at three viewports: 1. category headings — 33px each, and a page carries a different NUMBER of them depending on which categories it spans (see .wd-kb__q-cat) 2. the pager vanishing on a single-page category — 76px 3. a question wrapping to two lines — 16px per wrapped row, and on a phone at 390px, 81 of the 114 questions wrap ⚠ NONE OF IT APPLIES WITHOUT JS. No floor is set (--wd-kb-min-h is written by weight-designer-kb.js), nothing is clipped, and the pager is display:none — so a crawler and a JS-off visitor still get all 114 answers expanded in one flat list, which is the whole progressive-enhancement contract of this section. */ /* The FRAME. --wd-kb-min-h is the tallest page that CAN occur — the ten tallest rows in the corpus, summed, measured at the current viewport. No page of ten rows can beat the ten tallest rows, so a wrap can never grow it. ⛔ MINIMUM, NOT A CAP: an opened answer must still be free to push it taller. That is the one height change this section should make, and clamping it would scroll the answer inside a box instead. */ .wd-kb__viewport { position: relative; min-height: var(--wd-kb-min-h, 0px); } /* A search that matched nothing is the one place the floor should NOT hold: there is nothing to page, so a frame-height box of empty navy sitting above the "no answers" card would be all cost and no benefit. The pager goes with it — a pager over an empty frame is a control for a list that isn't there. */ .wd-kb--empty .wd-kb__viewport { min-height: 0; } .wd-kb--js.wd-kb--empty .wd-kb__pager { display: none; } /* Clipping is TRANSIENT — only while a turn runs. Permanent overflow:hidden would cut off an opened answer the moment it passed the floor. */ .wd-kb--js .wd-kb__viewport.is-turning { overflow: hidden; transition: height 0.28s cubic-bezier(0.16, 1, 0.3, 1); } /* The measuring pass: every row laid out at the real column width, off the paint. Absolute inside the relative frame keeps the width honest without the frame briefly growing to fit all 114 rows. */ .wd-kb__stack.is-measuring { position: absolute; left: 0; right: 0; top: 0; visibility: hidden; pointer-events: none; } .wd-kb__stack.is-measuring .wd-kb__category, .wd-kb__stack.is-measuring .wd-kb__item { display: block; } .wd-kb__stack.is-measuring .wd-kb__a { grid-template-rows: 0fr; } /* ⚠ ROWS ARE MEASURED TWICE, and the second pass is what this class is for. The in-row label takes its width off the question and can therefore CAUSE a wrap, so a row is a different height in "All" and in a search than it is in a single category. Packing a page against the wrong set either overfills it (the frame grows) or underfills it (dead space), so weight-designer-kb.js measures both and uses the set that matches the current view. */ @media (min-width: 900px) { .wd-kb__stack.is-measuring.is-measuring-multi .wd-kb__q-cat { display: block; } } /* ── the page turn ────────────────────────────────────────────────────────── The whole page moves as ONE block: the outgoing set rides up and out of the frame, then the incoming set follows it up from below. Never row by row — a stagger across ten rows reads as a carousel shuffling cards rather than a page being pushed past. --wd-kb-turn-d is the FRAME's height, written by the JS: a short page (a four-result search) is shorter than the frame it sits in, and translating by its own 100% would leave it mid-frame instead of below it. */ .wd-kb--js .wd-kb__stack { transition: transform 0.2s cubic-bezier(0.55, 0, 1, 0.45), opacity 0.2s cubic-bezier(0.55, 0, 1, 0.45); } .wd-kb__stack.is-out { transform: translateY(calc(-1 * var(--wd-kb-turn-d, 100%))); opacity: 0; } .wd-kb__stack.is-below { transform: translateY(var(--wd-kb-turn-d, 100%)); opacity: 0; } .wd-kb__stack.is-entering { transition: transform 0.28s cubic-bezier(0.16, 1, 0.3, 1), opacity 0.2s ease-out; } /* The single frame where the stack is repositioned below the frame after the swap. That jump must never tween, or it rides back down through the outgoing position and the turn reads as a bounce. */ .wd-kb__stack.no-anim { transition: none !important; } /* Answers are closed during the invisible half of the turn, so their own 0.6s collapse must not run — it would fight the frame's height tween. */ .wd-kb__stack.no-anim .wd-kb__a { transition: none; } /* ── the pager ────────────────────────────────────────────────────────────── ONE control for the whole list, never one per category: a page of "All" or of a search result spans categories, so a per-category pager could not describe what is on screen. ⛔ ALWAYS IN THE LAYOUT once JS is up, buttons and all — a category that fits on one page keeps the space and reads "Page 1 of 1" with both disabled. Letting it disappear moved everything below it by 76px. */ .wd-kb__pager { display: none; } .wd-kb--js .wd-kb__pager { display: flex; align-items: center; justify-content: space-between; gap: 12px; margin-top: 18px; padding-top: 16px; border-top: 1px solid rgba(255, 255, 255, 0.10); } .wd-kb__pager-btn { display: inline-flex; align-items: center; border: 1px solid rgba(255, 255, 255, 0.14); border-radius: 8px; background: transparent; color: rgba(255, 255, 255, 0.72); font: 600 13.5px/1 Montserrat, sans-serif; padding: 10px 15px; cursor: pointer; transition: background 0.16s ease, color 0.16s ease, border-color 0.16s ease; } .wd-kb__pager-btn:hover:not(:disabled) { background: rgba(77, 163, 255, 0.10); border-color: #4DA3FF; color: #fff; } .wd-kb__pager-btn:disabled { opacity: 0.28; cursor: default; } .wd-kb__pager-at { margin: 0; font-size: 12.5px; font-weight: 600; letter-spacing: 0.05em; color: rgba(255, 255, 255, 0.32); font-variant-numeric: tabular-nums; text-align: center; } .wd-kb__pager-at b { color: rgba(255, 255, 255, 0.72); font-weight: 700; } .wd-kb__pager-btn:focus-visible { outline: 2px solid #4DA3FF; outline-offset: 2px; } /* ── categories & items ── */ /* Panels are hidden by DEFAULT and the active one is marked in the generated markup — so the resting view is right at first paint. (Filtering them after load meant painting all nine categories and then collapsing eight, i.e. the same layout-shift problem as the answers.)