/* ========================================================================= Ridgeline — the design layer ========================================================================= Loads after upline-bones.css. Bones supplies the behaviour every Upline theme must have; this supplies how Ridgeline looks. The division, stated plainly because it is what keeps the system a system: if a rule would be true of EVERY Upline theme, it belongs in Bones. If it is true only of this design, it belongs here. WHAT THIS FILE MAY NOT DO ------------------------- - No selectors into upline-facets markup (.upline-*). Not one. As of plugin 1.15.0 the plugin's feel rules live in `@layer upline`, so an unlayered rule here would WIN with a single plain class and no !important. That is not permission. @layer removed the specificity trap and nothing else; the fragility ban stands, because __element and --modifier names still move between releases. Anything a token cannot reach is a token request. - No !important. Not one, anywhere, ever. There is no longer any case for it. - NEVER wrap this file in @layer. Unlayered theme declarations beating the plugin's layered ones is the mechanism the whole ownership line runs on — an unlayered stylesheet is load-bearing here, not untidy. (Build Spec hard rule 7.) - Never change chip height (36px), never hide disabled facet options, never make the mobile menu toggle depend on JavaScript. IF YOU EVER WRITE CHOREOGRAPHY, ANCHOR ON THE HOOKS --------------------------------------------------- The state hooks are the API; the elements currently carrying them are not. Anchor on `[data-upline-open]` as an attribute selector and on a bare `.is-open` with structural combinators — never on `.upline-mega` or `.upline-menu__drawer`, which are the carriers the docs happen to name today and may be renamed tomorrow. Hook-anchored choreography survives a rename; element-anchored choreography dies silently. MOBILE FIRST ------------ Every base rule below is the 390px case. Every media query is min-width. Nothing here was designed wide and squeezed down. BROWSER FLOOR ------------- Below Safari 15.4 / Chrome 99 / Firefox 97, @layer is unsupported and the plugin's layered styles drop entirely, rendering its surfaces unstyled. Check the browser version before investigating any "unstyled menu" report, or you will go hunting in CSS for a browser problem. OPEN TOKEN REQUESTS — do not work around these ---------------------------------------------- Both are raised against the plugin and both would be one unlayered line to "fix" here. Fixing them here papers over the exact gap the request exists to close, and the request then quietly dies. Ship the surface imperfect. 1. panelShadow — the mega panel's rgba(0,0,0,0.35) 0 14px 34px -18px is unreachable, and Ridgeline's rule is outlined-never-shadowed. 2. Panel radius wiring — the theme sets 2px, the panel computes 0px and ignores an override. Reads as a one-surface wiring gap, not a missing token. Resolved since 1.14.0: menu motion. The plugin no longer toggles `display`; panels transition through grid-template-rows/opacity/visibility/transform, driven by motionDuration, motionEasing, menuHiddenTransform and drawerHiddenTransform. It enforces prefers-reduced-motion itself, at important priority — this file does not need to write it. ========================================================================= */ /* ------------------------------------------------------------------------- 1. The mono treatment — Ridgeline's signature ------------------------------------------------------------------------- Uppercase, tight size, wide tracking. It appears on eyebrows, counts, chips, button labels and meta. Defined once as a class and inherited by the h6 element style in theme.json, rather than repeated at every call site. ------------------------------------------------------------------------- */ .rl-mono, .rl-eyebrow { font-family: var(--wp--preset--font-family--mono); font-size: var(--wp--preset--font-size--mono-sm); font-weight: 500; letter-spacing: var(--wp--custom--rl--mono-track, 0.14em); text-transform: uppercase; line-height: 1.3; } .rl-eyebrow { color: var(--wp--custom--rl--accent-ink); } /* Accent as INK wants the opposite lightness from accent as FILL, and once the fill end was pinned by white text (accent #d63700, 4.77:1) the ink end could no longer be the same value on dark grounds. Measured: #d63700 on the inverse ground drops to 4.13 stark / 3.77 warm — a regression the fill change caused. So ink is two derived values, neither shop-pickable, both in the private rl namespace because they are computed from the accent rather than chosen: accentInk #c33200 light grounds — 5.56 stark base / 4.57 warm surface accentOnInverse #ff4d14 dark grounds — 5.93 stark inv / 5.41 warm inv The dark-ground value is Ben's original vivid orange, retained exactly where it still works. Nothing was lost by darkening the fill; the old value moved to the surface it was always right for. accentInk is solved against the DARKEST light ground, not the lightest: warm editorial's `surface` (#efe8de) binds at 4.57, and base (#faf7f2) would have licensed a value three steps lighter that failed inside every surface band. tools/contrast-audit.mjs reads both palettes out of the JSON and enumerates the ground as a dimension, so "it passes on white" can no longer stand in for "it passes". The eyebrow appears on both kinds of ground (services is light; hero and the newsletter band are inverse), so the light value is the default and the dark containers override it. Link hover is the same story: theme.json sets the light-ground ink globally on elements.link:hover, and the same container set flips it, because a global hover colour reaches links inside dark bands too. The footer was already carved out; the others were not, which is the defect the ground-aware audit surfaced. */ .rl-announce .rl-eyebrow, .rl-footer .rl-eyebrow, .rl-section--inverse .rl-eyebrow, .rl-hero .rl-eyebrow, .rl-panel--dark .rl-eyebrow, .rl-announce a:hover, .rl-section--inverse a:hover, .rl-hero a:hover, .rl-panel--dark a:hover { color: var(--wp--custom--rl--accent-on-inverse); } /* ------------------------------------------------------------------------- 2. Header ------------------------------------------------------------------------- The bar is the theme's own markup, so its stickiness and its stuck-state transition are ours. The mega panel inside it is the plugin's and is untouched — see KNOWN PLUGIN GAPS 1. Sticky is CSS, so it works with JavaScript off. The compact stuck state is layered on top with a scroll-driven animation where the browser supports one, and simply does not happen where it does not. Nothing depends on a script, and nothing shifts layout: the bar's height is animated on a container that already reserves its own space. ------------------------------------------------------------------------- */ /* The sticky header: DELETED FROM THIS FILE at 2.11.2, expiry fired. ------------------------------------------------------------------------ This file carried an identical copy of Bones' sticky rule from 2.2.1, as a bridge: the rule belongs in Bones — a child cannot add a class to a template-part call inside a template it inherits — but a parent-theme update is a separate install step, and bikeco sat on Bones 2.2.0 for the whole of that period, which would otherwise have left the site with the sticky removed from the skin and not yet added to the chassis. The bridge carried a stated expiry: remove the copy once the served parent is Bones >= 2.2.1, read from the artifact the site hands out rather than from the version that left this bench. That read ran 2026-09-12, same-origin against `/wp-content/themes//style.css` with a per-request buster and `cache: no-store`: Bones 2.3.1, Ridgeline 2.11.1, both HTTP 200. Expiry satisfied, copy deleted, and the rule now lives in exactly one place — upline-bones.css section 4. This is the seam rule from the other direction: a rule that moved up and was left down became an opponent (the doubled icons, 2.10.0). This one was left down ON PURPOSE, with a written end date and a named condition, which is the whole difference between a bridge and a fork. The deletion is what makes the difference true rather than claimed. */ /* ========================================================================= 2.15.0 — THE HEADER'S MARKUP IS NO LONGER THIS THEME'S. READ THIS FIRST. ========================================================================= `parts/header.html` used to hold Ridgeline's own bar. It now holds Ridgeline's own CHROME — the announce strip and the `rl-header` wrapper — around a single plugin block, `upline-facets/header-option`, which renders whichever of Bones' six header patterns the shop has chosen. So every slot in the bar is Bones' markup now, and this file styles the chassis's slot classes instead of its own. THE RENAME MAP, so the measurements below stay readable: .rl-bar -> .ub-header the white band .rl-bar__row -> .ub-header__brand-row > div the wrapping row .ub-header__strip > div (and the category row) .rl-bar__row -> .ub-collapse resting/stuck heights only .rl-brand -> .ub-header__logo .rl-wordmark -> .ub-header__logo (img / a inside it) .rl-nav -> .ub-inline-menu .rl-actions -> .ub-header__actions .rl-search -> .ub-header__search (new) .ub-header__contact, .ub-header__secondary `.rl-header` and `.rl-announce` STAY, and `.rl-header` staying is deliberate rather than leftover: its `position: relative` is the mega panel's containing block, measured, and Bones sticks the OUTER template-part wrapper while leaving `.ub-header` unpositioned — so keeping this element keeps the panel resolving exactly where it resolves today. Dropping it would have handed the panel to a sticky ancestor and changed a measured desktop behaviour for no reason. EVERY MEASUREMENT QUOTED BELOW WAS TAKEN UNDER THE OLD CLASS NAME, on the old markup, and the prose says so rather than being rewritten to look current. The numbers are the record; renaming them would forge it. What that also means, and it is the honest caveat on this whole release: a compensation whose cause was the old arrangement has been RE-POINTED, not RE-MEASURED. Two of them are worth naming because the arrangement genuinely changed underneath them: - the 44px pin and `align-items: flex-start` on the menu box were measured with the menu INLINE in a single wrapping bar row. Two-row gives the menu its own full-width row. Their cause — a closed drawer taking its natural box in normal flow — is independent of which row it sits in, so they are kept; that reasoning is not a measurement. - the mobile `flex: 1 0 100%` on the logo faked "logo on top, controls beneath" inside one row. Two-row does that structurally. It is kept for the brand row, which still holds four items on one line at 390px. Rules asserted, render owed — and these two are the first place to look. ------------------------------------------------------------------------- */ /* The skin only. THE STICKY IS NOT HERE AND MUST NOT BE PUT BACK HERE. It lived on this selector through 2.2.0 and did nothing: WordPress wraps the header template part in its own `
`, so this element's parent is exactly as tall as this element, and a sticky box with zero travel scrolls away like an ordinary one. Bones now sticks the wrapper (see upline-bones.css §4). Re-adding `position: sticky` here is not a second belt — it re-establishes the inner element as its own containing context and breaks the working one. */ /* Two bands, not one. The mockup runs a dark announce strip over a WHITE main bar; the previous build painted the whole header inverse, which is the single biggest reason it did not read as the design. `position: relative` here is load-bearing — see .rl-nav below, which hands the mega panel this element as its containing block so it can span the viewport. */ .rl-header { position: relative; background-color: var(--wp--preset--color--base); color: var(--wp--preset--color--contrast); } .rl-header a { color: inherit; } .rl-announce { background-color: var(--wp--preset--color--inverse); color: var(--wp--preset--color--inverse-text); text-align: center; padding-block: var(--wp--preset--spacing--20); } /* `.rl-header` above is the ONE PAINTER for this header, and as of 2.15.6 that is a decision this file has to state rather than a fact it gets for free. Bones 2.3.29 paints `.ub-header` from `surface`, because the chassis makes the template-part wrapper sticky and range measured the whole stack transparent on bare Bones — scrolled content rendering through the bar. That fix is right and this skin asked for it. But `.ub-header` is the outermost group of every header pattern, so on Ridgeline the chassis's paint lands INSIDE `.rl-header` and on top of it: this theme's sheet depends on `upline-bones` and enqueues after it, so at equal specificity this rule wins, and without the declaration below the bar would come out `surface` where the approved comp has a WHITE bar under a dark announce strip. The chassis gaining a sensible default is exactly when a skin's silence stops being neutral. So the paint is handed back to `.rl-header` explicitly. Transparent rather than `base`: one painter is easier to reason about than two agreeing ones, and `.rl-header` has to paint anyway — it wraps the announce strip as well as the bar. Content cannot render through, because the opaque ancestor is `.rl-header` and it covers both. IF THIS SKIN EVER RENDERS A HEADER PART WITHOUT `.rl-header`, this declaration becomes the defect Bones just fixed, transplanted into the child. Gate 26 checks the invariant per artifact for that reason. */ .ub-header { background-color: transparent; border-bottom: 1px solid var(--wp--custom--upline--rule); } .rl-announce p { margin: 0; font-family: var(--wp--preset--font-family--mono); font-size: var(--wp--preset--font-size--mono-xs); letter-spacing: var(--wp--custom--rl--mono-track, 0.14em); text-transform: uppercase; } /* THE ANNOUNCEMENT SCROLLS AWAY AND ONLY THE BAR STICKS — 2.15.15, Ben's ruling. ------------------------------------------------------------------------ The chassis sticks the header TEMPLATE PART, not the bar inside it (2.3.29's docblock explains why at length: an inner sticky's containing block is the wrapper, which is only as tall as its own content, so it has no travel). This skin puts the announcement inside that part, so the whole 122.9px stuck — announcement included — and everything below it had to clear all of it. SO THE PART STILL STICKS AND THE SHED IS A NEGATIVE OFFSET. Pulling the sticky top up by the announcement's own height parks it above the viewport while the bar holds at the top. Nothing moves in the resting layout; only the stuck position changes. THE SHED IS ANNOUNCEMENT **PLUS BLOCK GAP**, and the second term is the one this bench got wrong first. Shedding only the announcement (29.9) left the bar's top at y20, with a 20px TRANSPARENT BAND above it where `.rl-header`'s block gap sits — and page content scrolled through that band. Measured: shed 29.9 announce bottom 0 bar y20 → 93 20px of page showing shed 49.9 announce bottom −20 bar y0 → 73 flush ✓ The gap is `--wp--style--block-gap`, which this theme's own theme.json sets to `spacing--60` — so it is read, not assumed to be 20. THE PIN, AND ITS CAVEAT, WHICH IS GATE 28'S. The shed needs the announcement's height as a number, so the height is pinned rather than left content-driven — a reservation that measures nothing is the defect gate 28 exists for, and an unpinned one here would silently stop matching. The cost is the other side of that same rule: **copy longer than one line will overflow this box rather than grow it.** One line of mono at this size is what the design is, the box is the skin's own content rather than a shop's free text, and an overflowing announcement is visible where a drifting shed would not be. If the announcement ever becomes shop-editable, this pin is the first thing that has to go. AND NO `overflow: hidden`, WHICH THIS RULE BRIEFLY HAD. Clipping the second line would protect the shed's arithmetic by hiding the evidence — a silent failure in place of a visible one, which is the exact trade the bottom bar's pin refused one release ago ("a visible defect in the bar rather than an invisible one in the page"). Spilling text is ugly and findable; a clipped word is neither. */ .rl-announce { block-size: var(--wp--custom--rl--announce-h, 30px); } .wp-site-blocks > header.wp-block-template-part { top: calc( var(--ub-sticky-top, 0px) - var(--wp--custom--rl--announce-h, 30px) - var(--wp--style--block-gap, var(--wp--preset--spacing--60)) ); } /* THE SKIN'S OWN TWO HEIGHTS ARE GONE — 2.15.15, Fault C ruled (a). ------------------------------------------------------------------------ This rule used to read: .ub-collapse { --ub-collapse-from: var(--wp--custom--rl--header-h, 64px); --ub-collapse-to: var(--wp--custom--rl--header-h-stuck, 52px); } and the paragraph above it argued that the two numbers were the skin's whole job here — "NOT the 72/44 the chassis defaults to … because this is Ridgeline's design" — and closed by predicting they were "the one thing in this release most likely to want moving". That prediction was right, and the argument was wrong in a way worth keeping rather than deleting: - 64 DID NOT DESCRIBE THIS BAR. The bar rests at 72 (44 of tap-sized controls + 28 of brand-row padding), so `--from: 64` was 8px under its own header. The outer `.ub-collapse` reserves `--from`, so the page height moved 8px during a collapse — the exact feedback the chassis primitive's docblock says the design prevents. Measured: resting outer 72, condensed outer 64. - 52 WAS NOBODY'S DRAWING. The chassis default 44 is 2a's spec exactly, and 44 is also the floor the mechanism can reach, because the content is tap-sized controls. Measured four ways in the Fault B record. So both numbers are deleted rather than corrected, and the chassis defaults stand: 72 → 44. `--wp--custom--rl--header-h` and `--rl--header-h-stuck` are removed from theme.json with them — the first had no consumer left once this rule went, and the second lost its last one when the buy column's offset moved to the chassis token (see the PDP note further down). A token nobody reads is the figure-nobody-owns-bumping problem in its smallest form, and this file has now deleted three of them for the same reason. WHY THEY ARE RESTATED ON `body` BELOW RATHER THAN SIMPLY DROPPED. The chassis declares both on `.ub-collapse`, and custom properties inherit downward only — measured on bikeco's PDP, `--ub-collapse-to` reads EMPTY on `body` and on `.rl-product__buy`, while a `settings.custom` token reads everywhere because WordPress emits those at root. So nothing outside the header can see the chassis's copy, and this skin has a sticky sibling in the page that needs the number. Restating at body level is what makes it readable there; `body.upline-header--