/** Shopify CDN: Minification failed

Line 870:70 Expected identifier but found whitespace
Line 883:75 Unterminated string token
Line 895:81 Unterminated string token

**/
/* ===========================================================================
   ROVE NEXT — two homepage corrections. 25 August 2026.
   Loaded on the index template only, LAST, so it wins on source order.
   =========================================================================== */

/* ---------------------------------------------------------------------------
   1. THE REYA CONFIGURATION THUMBNAILS WERE CUTTING THE SOFA IN HALF.

   Measured at 1440: the four thumbs are 139 x 104, a landscape frame of 1.336.
   Their sources are the _Display_ cut-outs, which are PORTRAIT at 0.799. With
   object-fit:cover that discards 40.2% of the height of every one of them, and
   what it discards is the bottom — so the base of the sectional is sliced off
   in all four.

   These thumbnails exist to let someone tell a 2 piece from a 4 piece and a
   left chaise from a right. That is a silhouette job, so the fit is contain,
   not cover. It is also what the PDP already does for the same purpose:
   .bb-cfgsil img in sections/rn-buybox.liquid is object-fit:contain.
   --------------------------------------------------------------------------- */
[id^="rn-hp-reya"] .rc-thumb img{
  object-fit:contain !important;
  object-position:50% 50% !important}

/* ---------------------------------------------------------------------------
   2. THE NEXT PROMISE STRIP AT HALF ITS HEIGHT.

   Sharon, 25 Aug: "the block is wayy too big. reduce size by 50%."

   Measured before: 315px tall for three short service lines on a dark ground.
   Three separate things were inflating it, each needing a different weight.

   a) THE 92px ROW FLOOR — the biggest one, and invisible in the markup.

        body #MainContent [id^="rn-hp-promise-"] .pr-row li
          { min-height:92px !important }

      Each row's real content is 46px: a 20px icon, an 8px gap and an 18px
      label. The floor was therefore holding 46px of pure empty space in every
      column — nearly a quarter of the whole block. Released below.

   b) THE HEADING was rendering at 40px, not the section's own
      clamp(19px,2.4vw,30px), because .rn-homepage-major-title from the shared
      homepage type scale was winning. One :not(#_):not(#__) pair clears it.

   c) THE PADDING needed a third guard. A generic rule

        [id^="rn-hp-"]:not(#_):not(#__) { padding: var(--rn-sep-half) !important }

      applies 72px to every homepage section at >=901px. It is (2,1,0) with
      !important — EXACTLY the specificity a [id^="rn-hp-promise"] rule with the
      same two guards would have — and it is emitted from a section <style> in
      the BODY, so on an equal-specificity !important tie it wins on source
      order and this file, being in the <head>, always loses. Hence the third
      :not(#___) plus html body: (3,1,2) against (2,1,0), so the result no
      longer depends on which one happens to come last.

      Anything overriding a homepage section's padding from a stylesheet needs
      the same treatment.

   Result: 315px -> about 163px, with the type and the icons still legible.
   The phone is unchanged; it already set its own 30px and was not the
   complaint.
   --------------------------------------------------------------------------- */
html body [id^="rn-hp-promise"]:not(#_):not(#__):not(#___){
  padding-top:36px !important;
  padding-bottom:36px !important}

@media(min-width:701px){
  [id^="rn-hp-promise"]:not(#_):not(#__) .pr-head{margin-bottom:16px !important}
  [id^="rn-hp-promise"]:not(#_):not(#__) .pr-head h2{
    font-size:24px !important;
    line-height:1.2 !important}
  [id^="rn-hp-promise"]:not(#_):not(#__) .pr-row{gap:20px !important}
  [id^="rn-hp-promise"]:not(#_):not(#__) .pr-row li{
    gap:16px !important;
    min-height:0 !important}
  /* ICON SIZE LIVES HERE, NOT IN THE SECTION FILE. 28 Aug 2026.
     This selector carries TWO ID units from :not(#_):not(#__), so it outranks
     the section's own #rn-hp-promise-<id> .pr-ic svg rule even though both are
     !important. Every earlier attempt to enlarge these marks was made in
     sections/rn-hp-promise.liquid and was silently dead on desktop — the
     section was asked three times for a bigger icon and could never deliver
     one above 700px. Sharon asked for 5x what she could actually see: the
     20px below became 100px. CHANGE IT HERE. The section file's desktop rule
     is kept in step at 100px so the two cannot disagree, but this is the one
     the browser obeys. */
  [id^="rn-hp-promise"]:not(#_):not(#__) .pr-ic svg{width:100px !important;height:100px !important}
  [id^="rn-hp-promise"]:not(#_):not(#__) .pr-lab{font-size:14px !important}
}

/* The phone keeps its own 30px, set by the section itself. Restate it here at
   the higher weight so the generic rule above cannot reach it either. */
@media(max-width:700px){
  html body [id^="rn-hp-promise"]:not(#_):not(#__):not(#___){
    padding-top:30px !important;
    padding-bottom:30px !important}
}

/* ============================================================================
   DESKTOP SECTION RHYTHM — ONE RULE, 72px. Sharon, 28 Aug 2026:
   "the homepage is missing the rule we have about padding after each section.
    I believe we had settled for 72px but now it looks massive."

   She was right on both counts. templates/index.json sets pad_top 72 and
   pad_bottom 72 on EVERY homepage section — her rule is there. Above 901px
   none of it renders, because three layers overrode it and then stacked:

     rn-hp-final-overrides.liquid  [id^="rn-hp-cards-"]              (0,1,0)
         the theme-editor 72/72 values. LOSES to everything below.
     rn-home-layout-system.css     body [id^=..]:not(#rn-desktop-lock) (1,1,1)
         forced padding 64 top / 32 bottom on ten sections.
     rn-next-three-polish.js       html body [id^=..]                (0,1,2)
         adds margin-top:96px to EVERY section, and tries to zero the padding
         but loses the padding half to the line above.

   The margin won and the padding won, so the two ADDED UP:
       32 (previous bottom) + 96 (margin) + 64 (next top) = 192px
   and it was not even consistent — motion and press are absent from the
   layout-system list so they kept padding 0 and measured 128, while promise
   sits at 36 from the block higher up this file. Between 128 and 192px
   depending on the pair, which is the unevenness Sharon was seeing.

   THE MODEL, and it is the one this build already uses on mobile (see the
   RN MOBILE SECTION RHYTHM HARD RULE in sections/rn-hp-promise.liquid):
   THE MARGIN IS THE GAP. Internal padding must never be used to fake it.
   So: 72px margin-top on every section, zero padding on the flat ones, and
   internal padding kept ONLY on the two blocks that carry their own
   background, where it is genuine breathing room inside a coloured band.

   :not(#_):not(#__) gives these rules two IDs of specificity, which is what it
   takes to beat all three layers above. See the note at the top of
   assets/rn-pdp-fit.css for the idiom.

   TO CHANGE THE RHYTHM, CHANGE THE 72 BELOW — it is now the only number that
   decides desktop section spacing on the homepage.
   ============================================================================ */
@media(min-width:901px){
  html body [id^="rn-hp-cards-"]:not(#_):not(#__),
  html body [id^="rn-hp-motion-"]:not(#_):not(#__),
  html body [id^="rn-hp-evo-"]:not(#_):not(#__),
  html body [id^="rn-hp-inr-"]:not(#_):not(#__),
  html body [id^="rn-hp-rts-"]:not(#_):not(#__),
  html body [id^="rn-hp-look-"]:not(#_):not(#__),
  html body [id^="rn-hp-add-"]:not(#_):not(#__),
  html body [id^="rn-hp-ugc-"]:not(#_):not(#__),
  html body [id^="rn-hp-rev-"]:not(#_):not(#__),
  html body [id^="rn-hp-press-"]:not(#_):not(#__){
    margin-top:72px !important;
    padding-top:0 !important;
    padding-bottom:0 !important;
  }

  /* The two sections with their own background keep INTERNAL padding, because
     there the padding is inside a coloured band rather than page whitespace.
     The gap before each is still the 72px above. */
  html body [id^="rn-hp-reya-"]:not(#_):not(#__){
    margin-top:72px !important;
    padding-top:64px !important;
    padding-bottom:64px !important;
  }
  html body [id^="rn-hp-promise-"]:not(#_):not(#__):not(#___){
    margin-top:72px !important;
    padding-top:36px !important;
    padding-bottom:36px !important;
  }

  /* The trust ribbon stays welded to the hero — it is part of it, not a
     section of its own. */
  html body [id^="rn-hp-trust-"]:not(#_):not(#__){
    margin-top:0 !important;
    padding-bottom:0 !important;
  }
}

/* ============================================================================
   THE FOUR "CHOOSE YOUR CONFIGURATION" THUMBNAILS — ONE RULE, EVERY WIDTH.
   Sharon, 28 Aug 2026, third report: "you still have not fixed the photo to
   move up / centered. cut off now."

   She was right, and the reason is at the top of this file. Correction 1 above
   sets object-fit:contain AND object-position:50% 50% on
   [id^="rn-hp-reya"] .rc-thumb img with !important and NO media query, so it
   applies at every width. The earlier fix went into
   assets/rn-reya-selector-equal.css, which is scoped to @media(min-width:901px)
   — so below 901px the rule above still decided the crop, and nothing changed.

   FOUR rules can reach this image. Ranked, !important first, then specificity:
     rn-reya-selector-equal.css  .rc-configchoice .rc-thumb img  (0,3,1) !  >=901 only
     rn-home-fixes.css (above)   .rc-thumb img                   (0,2,1) !  ALL widths
     rn-hp-reya.liquid L142      .rc-configchoice .rc-thumb img  (1,4,1)    no !important
     rn-hp-reya.liquid L131      .rc-thumb img                   (1,3,1)    no !important
   The two in the section file carry no !important, so they can never win.

   This rule ends the argument: (2,3,2) via :not(#_):not(#__), no media query,
   last in the last stylesheet the homepage loads. It targets ONLY
   .rc-configchoice — the size and chaise pickers keep the contain treatment
   from correction 1, which is right for them because those really are
   silhouette comparisons.

   THE NUMBERS. Sources are Reya_*_Display_1.jpg, 3200x4000 PORTRAIT (0.80).
   The sofa occupies rows 0.69-0.86 in all four files. With cover in a landscape
   frame of ratio r, the visible slice is 0.80/r of the image height:
       r = 1.32  ->  60.6%   band at 100% = 0.394-1.000
       r = 1.34  ->  59.7%   band at 100% = 0.403-1.000
       r = 1.46  ->  54.8%   band at 100% = 0.452-1.000
   At 100% the sofa sits INSIDE the band in every one of those, with floor
   beneath it — so this holds whichever frame ratio ends up applying, which is
   the point. At the old 66% the band ended at 0.846 and clipped the base:
   that is the slice Sharon has been looking at all along.
   ============================================================================ */
html body [id^="rn-hp-reya"]:not(#_):not(#__) .rc-configchoice .rc-thumb img{
  object-fit:cover !important;
  object-position:50% 100% !important;
}

/* ============================================================================
   FULL-BLEED PRODUCT CARDS. Sharon, 9 September 2026, relaying the CEO:
   "what he didn't like was how much white space there are around the margins...
    expand our three card block, make it bigger... let's build our page where it
    goes all the way to the edge, similar to how we have the hero banner."

   WHAT WAS HOLDING THE CARDS IN. Three layers, each stronger than the last, all
   saying the same 1320px:

     snippets/rn-vars.liquid       .rn-page                     max-width:--rn-max
     rn-home-layout-system.css     body [id^=..] .rn-page       (0,2,1) !important
     rn-home-desktop.css           body #MainContent [id^=..]   (1,2,1) !important

   So the container had to be beaten at ID weight. :not(#_):not(#__) is this
   build's existing idiom for that — see the DESKTOP SECTION RHYTHM block above
   and the note at the top of assets/rn-pdp-fit.css. This file loads LAST on the
   homepage, so it wins on order as well as weight.

   WHY THE CARD SHAPE IS NOT CHANGED HERE, though Sharon asked for squarer.
   sections/rn-hp-cards.liquid sets object-fit:CONTAIN on the card photograph,
   deliberately, so it is never cropped — and the 5/4 box matches the 5:4
   sources (3200x2560) almost exactly, which is why they currently fill the box
   edge to edge with no letterboxing. Make the box square and CONTAIN does not
   crop to fill it, it LETTERBOXES: bars top and bottom, and the backdrop seam
   on show. The same trap was hit on 3 September, when the box went to 16/9 and
   was reverted the same day (see the note in rn-home-desktop.css).

   Going full width already makes the photographs much larger — the box grows
   with the container. A genuinely square card needs either square photography
   or a switch to object-fit:cover, which this build has now twice decided
   against. That is a call for Sharon, not a CSS default.

   TO DIAL IT BACK: --rn-card-bleed is the only number. 0 is edge to edge;
   set it to 24px or 32px to hold the cards off the browser edge.
   ============================================================================ */
:root{
  /* THE SIDE GUTTER, AND THE ONLY NUMBER THAT DECIDES IT.

     Sharon, 9 Sep, looking at the published page: edge to edge is too wide,
     "give it some cushion... take it down a notch, maybe twenty five percent
     on each side."

     Twenty-five a side is half the page, and on a 1920 screen that lands each
     card at 304px — SMALLER than the 424px they were before any of this, and
     half their current 624px. It would undo the thing she asked for first,
     which was bigger cards. So this is 6%: a visible margin, cards still 547px,
     about 29% larger than the original. Measured, not guessed.

         gutter   content   each card
           0%      1920px     624px     edge to edge
           4%      1766px     573px
           6%      1690px     547px     <- here
           8%      1613px     522px
          12%      1459px     470px
          25%       960px     304px     narrower than before the change
         (was 1320px cap        424px)

     A percentage rather than pixels so it holds its proportion from a laptop to
     a 5K display, where a fixed gutter would look mean on one and enormous on
     the other. */
  --rn-card-bleed:6%;
  --rn-card-gap:24px;
}
@media(min-width:901px){
  html body [id^="rn-hp-cards-"]:not(#_):not(#__) .rn-page{
    max-width:none !important;
    width:100% !important;
    margin-left:0 !important;
    margin-right:0 !important;
    padding-left:var(--rn-card-bleed) !important;
    padding-right:var(--rn-card-bleed) !important;
  }

  /* The three cards keep their gap between each other; only the outer edges go
     to the page edge, which is what "full bleed" means here. */
  html body [id^="rn-hp-cards-"]:not(#_):not(#__) .hp-grid{
    grid-template-columns:repeat(3,minmax(0,1fr)) !important;
    gap:var(--rn-card-gap) !important;
  }

  /* The heading is prose and stays on a reading measure — a 44px line running
     the full width of a 2560px monitor is not a headline, it is a rule. The
     centred 760px it already had is kept explicitly, because the container it
     used to inherit that from is now full width. */
  html body [id^="rn-hp-cards-"]:not(#_):not(#__) .hp-head{
    max-width:760px !important;
    margin-left:auto !important;
    margin-right:auto !important;
    padding-left:24px !important;
    padding-right:24px !important;
  }
}

/* ============================================================================
   FULL BLEED, THE REST OF THE PAGE. Sharon, 9 September 2026: "let's build our
   page where it goes all the way to the edge... and it should go throughout the
   entire page."

   The three-card block went first so she could see it. This carries the same
   treatment down the page — but NOT to every section, and the distinction is
   the whole design decision here.

   PHOTOGRAPHY GOES EDGE TO EDGE. PROSE DOES NOT.

   A photograph gains from width: the wider the frame, the more of the room you
   see, and the sofa gets bigger. A paragraph loses from it. Running body copy
   across a 2560px monitor gives lines of 200+ characters, which nobody reads —
   they skip. So the sections below open their CONTAINER to the page edge while
   every heading and paragraph inside stays on a reading measure.

   FULL BLEED HERE:
     rn-hp-inr-     Made to Be Lived On   image + copy row
     rn-hp-look-    the look block        photography
     rn-hp-ugc-     At Home With Us       a grid of customer photos
     rn-hp-motion-  the motion band       already one full-width stage

   DELIBERATELY LEFT ALONE, and each for its own reason:
     rn-hp-reya-    carries its own background band. Full-bleeding the band is
                    fine; full-bleeding the CONFIGURATOR inside it would put the
                    swatches a metre from the product. Needs its own pass with
                    eyes on it.
     rn-hp-rts-     a row of cards already capped at 360px each. Widening the
                    container just spreads three cards further apart.
     rn-hp-add-     deliberately the narrowest block on the page (1120/900).
     rn-hp-promise- / rev- / press-   these ARE prose. Wider is worse.

   Same idiom and the same single knob as the cards block: --rn-card-bleed.
   ============================================================================ */
@media(min-width:901px){
  html body [id^="rn-hp-inr-"]:not(#_):not(#__) .rn-page,
  html body [id^="rn-hp-look-"]:not(#_):not(#__) .rn-page,
  html body [id^="rn-hp-ugc-"]:not(#_):not(#__) .rn-page,
  html body [id^="rn-hp-motion-"]:not(#_):not(#__) .rn-page{
    max-width:none !important;
    width:100% !important;
    margin-left:0 !important;
    margin-right:0 !important;
    padding-left:var(--rn-card-bleed) !important;
    padding-right:var(--rn-card-bleed) !important;
  }

  /* THE COPY COLUMN STAYS READABLE. "Made to Be Lived On" is a two-column row —
     picture one side, words the other. With the row now spanning the viewport
     the words would stretch with it, so the text column keeps a fixed measure
     and the photograph takes the space that frees up. That is the point of the
     change: more picture, not longer lines. */
  html body [id^="rn-hp-inr-"]:not(#_):not(#__) .ir-row{
    grid-template-columns:minmax(0,1.35fr) minmax(360px,.65fr) !important;
    gap:clamp(44px,4vw,80px) !important;
    align-items:center !important;
  }
  html body [id^="rn-hp-inr-"]:not(#_):not(#__) .ir-copy{
    max-width:520px !important;
  }

  /* Headings and standfirsts across all four stay centred on a reading measure,
     for the same reason a newspaper does not set a headline across six columns. */
  html body [id^="rn-hp-inr-"]:not(#_):not(#__) .ir-head,
  html body [id^="rn-hp-look-"]:not(#_):not(#__) .hp-head,
  html body [id^="rn-hp-ugc-"]:not(#_):not(#__) .hp-head{
    max-width:760px !important;
    margin-left:auto !important;
    margin-right:auto !important;
    padding-left:24px !important;
    padding-right:24px !important;
  }
}

/* ============================================================================
   MADE TO BE LIVED ON, BUILT TO SHARON'S REFERENCE.

   Sharon, 9 September, sending a competitor page: match the way the photo and
   the text box sit, and "use that same measurement for our white cushion."

   MEASURED OFF HER SCREENSHOT rather than approximated by eye. On a ~1900px
   viewport the reference resolves to:

       side cushion      237px each side        12.5% of the viewport
       content           1438px                 75.7%
       image             720 x 535              ratio 1.35, near enough 4:3
       image share       50.1% of the row
       gap to the text   133px
       text column       585px                  40.7%
       text is vertically CENTRED on the image  (both midpoints land at ~320)

   So: columns of 1.23fr to 1fr, a 133px gap, and a 4:3 photograph.

   THE CUSHION IS ITS OWN NUMBER, not the cards'. --rn-card-bleed is 6% and
   Sharon has just approved how the cards look at that width; the reference
   wants twice as much air. Sharing one variable would have moved the cards the
   moment this section changed, so this gets --rn-inr-bleed and the two can be
   tuned independently.

   WHY 4:3 IS SAFE HERE, WHEN CROPPING THE CARDS WAS NOT. The card photographs
   are product shots on a plain wall — crop them and the sofa fills the frame
   and reads as a close-up, which is what went wrong an hour ago. This is a
   LIFESTYLE image: a room with a person in it. Those are shot loose on purpose
   and the subject sits mid-frame, so a 4:3 window holds the subject with room
   around it. Different photograph, different rule.
   ============================================================================ */
@media(min-width:901px){
  :root{ --rn-inr-bleed:12.5%; }

  html body [id^="rn-hp-inr-"]:not(#_):not(#__) .rn-page{
    padding-left:var(--rn-inr-bleed) !important;
    padding-right:var(--rn-inr-bleed) !important;
  }

  html body [id^="rn-hp-inr-"]:not(#_):not(#__) .ir-row{
    grid-template-columns:minmax(0,1.23fr) minmax(0,1fr) !important;
    gap:clamp(48px,7vw,133px) !important;
    align-items:center !important;
  }

  /* 4:3, matching the reference. The photograph leads the row and the copy
     answers it, rather than the two competing for the same height. */
  html body [id^="rn-hp-inr-"]:not(#_):not(#__) .ir-media{
    aspect-ratio:4 / 3 !important;
  }

  /* 585px is the reference's text column. Left as a max rather than a width so
     a longer paragraph wraps inside it instead of pushing the photograph. */
  html body [id^="rn-hp-inr-"]:not(#_):not(#__) .ir-copy{
    max-width:585px !important;
  }

  /* The heading belongs to the copy column here, not centred over the whole
     row — the reference sets it hard left above its own paragraph, and a
     centred heading over an asymmetric row reads as a mistake. */
  html body [id^="rn-hp-inr-"]:not(#_):not(#__) .ir-head{
    max-width:none !important;
    margin-left:0 !important;
    margin-right:0 !important;
    padding-left:0 !important;
    padding-right:0 !important;
    text-align:left !important;
    margin-bottom:0 !important;
  }
  html body [id^="rn-hp-inr-"]:not(#_):not(#__) .ir-head p{
    margin-left:0 !important;
    margin-right:0 !important;
    max-width: none !important;
  }
}

/* ============================================================================
   MADE TO BE LIVED ON — THE BEIGE MOVES UP A ROW, AND THE SECTION GETS AIR.

   Sharon, 9 September 2026, two notes on the same section:

     "I need some breathing space right above it because it's just too close to
      the three shots... so add some space."

     "The first one, where you have Made to Be Lived On and then Certified where
      it counts — I think that section should have the beige background, and
      then it'll be white for the 100,000 rub. Right now you have the beige on
      the other one. That way there's a bit of a separation between Made to Be
      Lived On and the three cards above."

   She is describing the current state exactly. The section root is WHITE
   (--rnhp-card, set by the surface map in snippets/rn-hp-kit.liquid), row one
   carries no ground of its own so it shows that white, and row two is the one
   stone band. Beige on the second row, white on the first. She wants it the
   other way round, and the reason she gives is the one that decides how this is
   built: SEPARATION FROM THE CARDS ABOVE.

   WHY THE ROOT MOVES AND NOT JUST THE FIRST BAND. The heading "Made to Be Lived
   On" is NOT inside a band — it sits in the section root, above the loop. Colour
   only the first band and the heading stays on white above it, the beige starts
   abruptly halfway down, and the top of the section still runs into the cards.
   White against the cards' page tone measures 1.09:1, which is no edge at all —
   that near-invisibility IS the thing she is pointing at. So the root takes the
   stone, which puts the heading and row one on one continuous beige, and the
   section announces itself the moment it starts.

   THE BANDS ARE INVERTED, NOT REASSIGNED. sections/rn-hp-innovation-rows.liquid
   computes the ground from the row's index — `side = ri modulo 2` — precisely so
   rows can be added, deleted or dragged without anyone re-setting a colour by
   hand. Naming a specific row here would throw that away. Instead the root
   supplies stone to every unclassed band, and .is-stone — which now sits on the
   OPPOSITE rows to the ones it names — is repainted white. Row one stone, row
   two white, row three stone, and a fourth row would still be correct.

   The class name now says the opposite of what it paints. That is the cost of
   keeping the alternation automatic, and it is why this comment is long.

   THE IMAGE SIDES ARE NOT TOUCHED. The same `side` variable drives .ir-row.flip.
   Sharon asked about colour only, and the photographs already alternate down the
   page correctly — inverting the ground in CSS leaves the flip alone, which is
   the main reason this is done here rather than in the Liquid.

   THE HAIRLINE FOLLOWS THE STONE. The section puts an inset rule on .ir-media
   when it sits on stone, because the sand plate (--rn-sand, and rows one and two
   are both still plates awaiting photography) loses its edge against stone at
   1.21:1. Now that stone has moved, the hairline moves with it — otherwise it
   would be drawing an edge on the one row that no longer needs one, and omitting
   it from the two that do.

   THE SURFACE MAP IN rn-hp-kit.liquid STILL READS --rnhp-card FOR THIS SECTION.
   The line below supersedes it. That map is meant to be the one place the page's
   ground sequence can be read end to end, so this is a debt, not a pattern: fold
   it back in when that file is next edited, the way the kit itself asks to be
   folded into rn-vars. Re-checked against the ACTUAL render order in
   templates/index.json, which is NOT the order the kit's map comment lists: the
   three product cards sit directly above (page tone — 1.10:1 against stone, so
   the new edge reads) and the motion band directly below (its own full-width
   photographic stage, not on the ground map at all). No adjacency clash.
   ============================================================================ */
html body [id^="rn-hp-inr-"]:not(#_):not(#__){
  background:var(--rnhp-stone) !important;

  /* The heading now sits INSIDE a coloured band, so it needs padding rather
     than the zero the desktop rhythm block gives flat sections — without this
     the words touch the top edge of the beige. Deliberately outside a media
     query: below 901px the section sets its own padding from the theme-editor
     sliders, and this has to beat that too, so there is one rule for every
     width instead of two that can drift apart. */
  padding-top:clamp(32px,5vw,72px) !important;
}
html body [id^="rn-hp-inr-"]:not(#_):not(#__) .ir-band.is-stone{
  background:var(--rnhp-card) !important;
}

html body [id^="rn-hp-inr-"]:not(#_):not(#__) .ir-band.is-stone .ir-media{
  box-shadow:none !important;
}
html body [id^="rn-hp-inr-"]:not(#_):not(#__) .ir-band:not(.is-stone) .ir-media{
  box-shadow:inset 0 0 0 1px var(--rn-line) !important;
}

@media(min-width:901px){
  /* THE AIR ABOVE. The homepage rhythm is 72px and the block near the top of
     this file calls that "the only number that decides desktop section
     spacing" — so this is a stated exception, not a second opinion. It earns
     one for the same reason rn-hp-reya- and rn-hp-promise- have theirs: the
     section now carries its own background, so the gap above it is not
     whitespace between two blocks of prose, it is the edge of a coloured band.
     108px is 1.5x the rhythm — clearly more air, still a multiple of it. */
  html body [id^="rn-hp-inr-"]:not(#_):not(#__){
    margin-top:108px !important;
  }
}

/* ============================================================================
   THE THREE PROOF-ROW MEDIA BOXES WERE NOT THE SAME SIZE. THIS IS A REAL BUG,
   NOT A TASTE CALL.

   Sharon, 9 September 2026: "the photos for each section is all different size
   ... use the same size that you have under Certified where it stands. I want
   the image block or the video block to be that size for Built for everyday
   life as well as Spills bead at the surface. Those three sections should be
   completely consistent in terms of size."

   WHAT WAS ACTUALLY HAPPENING — a CSS Grid trap, and worth writing down because
   it is invisible in the markup and will be reintroduced by anyone who reads
   the section file alone.

   The row is a two-column grid, deliberately asymmetric so the photograph leads:

       grid-template-columns: minmax(0,1.23fr) minmax(0,1fr)

   and the markup order is ALWAYS media, then copy. The alternating layout is
   produced by sections/rn-hp-innovation-rows.liquid re-ordering the two children
   on odd rows rather than rebuilding the row, so a screen reader gets the same
   sequence every time:

       .ir-row.flip .ir-media{order:2}
       .ir-row.flip .ir-copy {order:1}

   That is good markup practice and it is exactly what broke the sizing. Grid
   auto-placement walks items in ORDER-MODIFIED document order, not document
   order. So on a flipped row .ir-copy is placed FIRST and takes column one —
   the 1.23fr column — and .ir-media is pushed into column two, the 1fr one.

   The media box therefore alternated between the wide column and the narrow
   column all the way down the section:

       i1  Certified where it counts   not flipped   1.23fr   WIDE
       i2  Built for everyday life     flipped       1fr      NARROW
       i3  Spills bead at the surface  not flipped   1.23fr   WIDE

   and because .ir-media carries a fixed aspect-ratio, a narrower box is also a
   SHORTER one — so row two was smaller in both dimensions. That is what Sharon
   is looking at.

   THE FIX: PLACE THE ITEMS EXPLICITLY, AND FLIP THE COLUMN WIDTHS WITH THEM.
   Every media box now takes 1.23fr and every copy column 1fr, whichever side of
   the row it happens to be on — so all three are identical, and they match i1,
   which is the one she asked the other two to match.

   `order` is deliberately left in place in the section file. Once an item has a
   definite grid position it is no longer auto-placed, so order cannot move it
   any more; it only affects paint order, which is harmless. Removing it would be
   a second edit to a signed-off file for no behavioural gain.

   SCOPED TO 901px AND UP ON PURPOSE. Below that the section collapses to a
   single column and uses `order` to stack picture above copy — pinning
   grid-column and grid-row there would drop both children into one cell.
   ============================================================================ */
@media(min-width:901px){
  html body [id^="rn-hp-inr-"]:not(#_):not(#__) .ir-row{
    grid-template-columns:minmax(0,1.23fr) minmax(0,1fr) !important;
  }
  html body [id^="rn-hp-inr-"]:not(#_):not(#__) .ir-row.flip{
    grid-template-columns:minmax(0,1fr) minmax(0,1.23fr) !important;
  }

  html body [id^="rn-hp-inr-"]:not(#_):not(#__) .ir-row .ir-media{
    grid-column:1 !important;
    grid-row:1 !important;
  }
  html body [id^="rn-hp-inr-"]:not(#_):not(#__) .ir-row .ir-copy{
    grid-column:2 !important;
    grid-row:1 !important;
  }
  html body [id^="rn-hp-inr-"]:not(#_):not(#__) .ir-row.flip .ir-media{
    grid-column:2 !important;
  }
  html body [id^="rn-hp-inr-"]:not(#_):not(#__) .ir-row.flip .ir-copy{
    grid-column:1 !important;
  }
}

/* ============================================================================
   START WITH TWO — THE INTRO SET CENTRED.

   Sharon, 9 September 2026, giving the copy as three deliberate lines and
   asking for centre alignment: "write like this on 3 lines and center
   alignment. try this."

   THE LINE BREAKS ARE DATA, NOT CODE. .rc-intro already carries
   white-space:pre-line, so the newlines she typed into the section's Intro
   field render as real breaks. The copy change is in templates/index.json and
   nothing in the section file had to move for it — which also means she can
   re-break the lines herself in the theme editor without asking.

   WHY THE WHOLE HEAD GROUP IS CENTRED AND NOT JUST THE PARAGRAPH. On desktop
   this copy sits in the right-hand column beside the product shot, above an
   OEKO pill, a two-up feature list and the configuration picker — all of them
   left-aligned. A single centred paragraph directly beneath a left-aligned
   eyebrow and headline does not read as a choice, it reads as a mistake. So the
   eyebrow, the headline and the intro are centred together as one block, which
   is a treatment, and the functional controls below stay left where they
   belong.

   If Sharon wants only the paragraph moved, delete .rc-eyebrow and h2 from the
   selector below. If she wants the entire column centred, the pill and feature
   list need their own handling — they are inline-flex and a two-column grid, so
   text-align alone will not do it.

   MOBILE IS UNTOUCHED. .rc-mobile-head is a separate element and has been
   centred since the section was built; this rule names the desktop head only.
   ============================================================================ */
@media(min-width:901px){
  html body [id^="rn-hp-reya-"]:not(#_):not(#__) .rc-desktop-head,
  html body [id^="rn-hp-reya-"]:not(#_):not(#__) .rc-desktop-head h2,
  html body [id^="rn-hp-reya-"]:not(#_):not(#__) .rc-desktop-head .rc-eyebrow,
  html body [id^="rn-hp-reya-"]:not(#_):not(#__) .rc-desktop-head .rc-intro{
    text-align:center !important;
  }
}

/* ============================================================================
   REYA INTRO — HOLDING IT TO THREE LINES. MEASURED, NOT NUDGED.

   Sharon, 9 September: "The word 'space changes' is going on the fourth line.
   Move it onto the third line and keep three lines only."

   THE MEASUREMENT, taken from the real Urbanist TTF rather than estimated:

       longest line, 17px, letter-spacing .01em ......... 675px
       the h2 beside it, 44px weight 500 ................ 662px

   The heading renders on ONE line, so the copy column is at least 662px — and
   the paragraph misses by THIRTEEN PIXELS. That is the whole bug. It is not a
   layout fault and nothing needs restructuring; the line is simply a hair too
   long for the measure it was given.

   At 16px the same line measures 636px, which clears the width we can prove the
   column has by 26px. One pixel of type size is not a visible change and it is
   the smallest instrument that fixes this — widening the column would move the
   configurator, and rewriting her sentence is not mine to do.

   width:max-content DOES THE REST. With white-space:pre-line already on this
   paragraph, max-content sizes the box to its longest hard-broken line, so the
   box hugs exactly her three lines and centres as a block. max-width:100% keeps
   it honest: on a narrower desktop the box simply clamps and the text wraps as
   before rather than overflowing into the photograph.
   ============================================================================ */
@media(min-width:901px){
  html body [id^="rn-hp-reya-"]:not(#_):not(#__) .rc-desktop-head .rc-intro{
    font-size:16px !important;
    width:max-content !important;
    max-width:100% !important;
    margin-left:auto !important;
    margin-right:auto !important;
  }
}

/* ============================================================================
   THE PROOF ROWS NOW LINE UP CORNER TO CORNER.

   Sharon, 9 September, with a reference screenshot: "the two corners should
   almost be in alignment ... they start and end in alignment with each other.
   We don't have to touch each other at the corner because we have the white
   space in between each section, but at least the alignment is corner to
   corner."

   She is asking for one vertical line down the middle of the section: row one's
   picture ENDS on it, row two's picture BEGINS on it, row three's ENDS on it.

   WHY IT WAS OFF, AND WHY IT LOOKED FINE ON A SMALLER SCREEN. The rows were
   1.23fr : 1fr, and that ratio only lands on a shared centre line for one
   particular gap. Writing W for the content width and G for the gap:

       row 1 picture ends at    0.5516 x (W - G)
       row 2 picture starts at  0.4484 x (W - G) + G
       drift                  = 0.1031 x (W - G) - G

   The gap is clamp(48px, 7vw, 133px), so while 7vw is still under 133px the two
   terms cancel and the drift is under a pixel — which is why this looked right
   at 1440 and 1792. Above about 1900px the gap STOPS growing and the drift
   opens up fast: ~24px at 2200, ~51px at 2560. On Sharon's 27-32" monitor it is
   plainly visible. It was never a robust alignment, only a coincidental one.

   THE FIX MAKES IT EXACT BY CONSTRUCTION, AT EVERY WIDTH. Give the picture
   column exactly 50% and let the copy take what is left after the gap:

       normal row   50%  |  1fr      picture ends at    0.5W
       flipped row  1fr  |  50%      picture starts at  (0.5W - G) + G = 0.5W

   Both land on 0.5W with no dependence on the gap at all. The pictures also
   stay identical in size — 50% of W on both sides — so the sizing fix directly
   above still holds.

   AND IT BARELY MOVES ANYTHING. At 1920 the picture goes from 721px to 720px
   and the copy column from 586px to 587px. The reference proportions Sharon
   approved are preserved to within a pixel; only the drift is gone.
   ============================================================================ */
@media(min-width:901px){
  html body [id^="rn-hp-inr-"]:not(#_):not(#__) .ir-row{
    grid-template-columns:50% minmax(0,1fr) !important;
  }
  html body [id^="rn-hp-inr-"]:not(#_):not(#__) .ir-row.flip{
    grid-template-columns:minmax(0,1fr) 50% !important;
  }
}

/* ============================================================================
   THE DIANE FILM — ONE SCREEN, NOT TWO. AND AIR ABOVE IT.

   Sharon, 9 September: "The Diane reengineered, some room above that ... it
   needs some cushion so it's not so close together. Number two, the image or
   the video is so big. It takes two full size screenshots to see the entire
   video. Take it down. Make it so that I can see one video in one screen."

   THE ARITHMETIC. .mo-stage is width:100% at aspect-ratio 16/9, and this
   section is full-bleed, so on a 1920 screen it is 1690 wide and therefore
       1690 x 9/16 = 951px TALL
   before the heading (~150px) and the Shop Diane button (~82px) are counted.
   That is ~1180px of section on a viewport that has maybe 930px of usable
   height once the sticky header and the countdown bar are subtracted. Hence two
   screenshots.

   SIZE IT FROM THE HEIGHT, NOT THE WIDTH. This is the only reliable way to make
   something fit a screen. The width is set to whichever is smaller: the
   container, or the width that produces a 56vh-tall frame. Height then follows
   from the aspect ratio, so the film is never distorted and never cropped, and
   the box cannot overflow its container.

       at 1920x1080   56vh = 605px tall, so 1075px wide, centred
       total section  ~150 + 44 + 605 + 32 + 50  =  ~880px       one screen

   WHY NOT max-height. A block-level box with width:100% takes its width from
   the container first; max-height then clamps the height and BREAKS the ratio,
   leaving object-fit:cover to crop the film. Setting the width is what keeps
   16/9 intact.
   ============================================================================ */
@media(min-width:901px){
  html body [id^="rn-hp-motion-"]:not(#_):not(#__){
    margin-top:108px !important;
  }
  html body [id^="rn-hp-motion-"]:not(#_):not(#__) .mo-stage{
    width:min(100%, calc(56vh * 16 / 9)) !important;
    margin-left:auto !important;
    margin-right:auto !important;
  }
}

/* ============================================================================
   #ATHOMEWITHNEXT — AIR AROUND THE BAND, AND PORTRAIT CARDS AGAIN.

   Sharon, 9 September: "You need some breathing room before At Home With Next,
   so it's not cut off right there. Add some cushion space. Also the image is
   too short. It also needs cushion after the assets. Right now we're seeing
   four of them in picture, but it needs to be longer, taller — right now it
   looks very squished."

   TWO SEPARATE FAULTS, and the padding one is the same trap as Made to Be Lived
   On. This section stands on the stone ground from the surface map, but the
   desktop rhythm block near the top of this file zeroes the padding of every
   flat section — and this one is not flat. So the heading sat ~22px below the
   top edge of its own coloured band and the cards ran to ~25px off the bottom.
   The band needs padding INSIDE it, which is exactly the exception already
   granted to rn-hp-reya- and rn-hp-promise-.

   THE CARDS: 1/1 GOES BACK TO PORTRAIT. They were changed to square on 27
   August to match the PDP "At Home With Us" galleries. That was a reasonable
   consistency argument then, but it is wrong for this content: creator photos
   are shot for Instagram, which is 4:5, so a square crop throws away the top
   and bottom of every frame and leaves a row of stubby tiles — Sharon's
   "squished". 4/5 is the ratio the photographs were composed in.

   THIS DIVERGES FROM THE PDP GALLERIES ON PURPOSE. They stay square. If someone
   later wants them unified again, unify on 4/5 rather than reverting this — the
   crop should follow the photography, and it is the same photography.

   Fewer cards are visible at once as a result, which is the intended trade: the
   carousel scrolls, so nothing is lost, and each photograph is bigger.
   ============================================================================ */
@media(min-width:901px){
  html body [id^="rn-hp-ugc-"]:not(#_):not(#__){
    margin-top:108px !important;
    padding-top:72px !important;
    padding-bottom:72px !important;
  }
  html body [id^="rn-hp-ugc-"]:not(#_):not(#__) .hp-card{
    aspect-ratio:4 / 5 !important;
  }
}

/* ============================================================================
   THE STAGED SCENE WAS SWALLOWING THE COLOURWAY PICKER. TWO SECTIONS, ONE BUG.

   Sharon, 9 September: "If I hover over anywhere in the card it does change to
   the render scene. But that breaks the function where I can select the
   colourways ... fix it where the render scene only shows up if I hover over
   the image itself, then the colourway I select should change so I can see what
   it is." And a minute later: "the issue I just flagged is happening to the same
   block, Ready Sooner Than You Think."

   WHY IT LOOKED LIKE THE SWATCHES WERE DEAD. They were not. The reveal is a
   pure CSS cross-fade keyed on the WHOLE CARD:

       .hp-card:hover .hp-media img.hp-scene{opacity:1}   /* room shot in  */
       .hp-card:hover .hp-media img.hp-shot {opacity:0}   /* product out   */

   The colourway dots sit inside that same card, below the photograph. So the
   moment the cursor travels down to a dot the card is still hovered, the room
   shot is still covering the frame, and the product shot underneath — the one
   the dot just changed — is at opacity 0. The click worked perfectly every
   time; the result was simply painted over. Nothing was broken in the picker.

   THE FIX GATES THE REVEAL ON THE PHOTOGRAPH, NOT THE CARD, and does it by
   turning the scene OFF for the one state that was wrong rather than by
   re-declaring the whole interaction:

       card hovered AND media NOT hovered  ->  scene out, product back in

   When the cursor is actually on the photograph this rule does not match and
   the section's own rule still runs, untouched. Hover the picture, get the
   room; move down to the swatches, get the product in the colour you picked.

   KEYBOARD IS HANDLED SEPARATELY AND DELIBERATELY. The obvious move — gating
   :focus-within on .hp-media too — would have killed the keyboard reveal
   outright, because nothing inside the photograph is focusable; the scene would
   then be mouse-only, which is what the section header says it was written to
   avoid. So focus keeps revealing the scene anywhere on the card EXCEPT while a
   colourway dot itself holds focus, which is the exact keyboard equivalent of
   Sharon's complaint: tab to a swatch and you must be able to see the swatch's
   colour, not the room.

   :has() is used for that, and it is already this build's idiom — the homepage
   section order in assets/rn-home-layout-system.css is built on body:has(...).
   ============================================================================ */

/* ---- the three product cards ---- */
html body [id^="rn-hp-cards-"]:not(#_):not(#__) .hp-card:hover .hp-media:not(:hover) img.hp-scene,
html body [id^="rn-hp-cards-"]:not(#_):not(#__) .hp-card:focus-within:has(button.hp-dot:focus) .hp-media img.hp-scene{
  opacity:0 !important;
}
html body [id^="rn-hp-cards-"]:not(#_):not(#__) .hp-card:hover .hp-media:not(:hover) img.hp-shot,
html body [id^="rn-hp-cards-"]:not(#_):not(#__) .hp-card:focus-within:has(button.hp-dot:focus) .hp-media img.hp-shot{
  opacity:1 !important;
}

/* ---- Ready Sooner Than You Think ---- */
html body [id^="rn-hp-rts-"]:not(#_):not(#__) .rs-item:hover .rs-media:not(:hover) img.rs-scene,
html body [id^="rn-hp-rts-"]:not(#_):not(#__) .rs-item:focus-within:has(button.rs-dot:focus) .rs-media img.rs-scene{
  opacity:0 !important;
}
html body [id^="rn-hp-rts-"]:not(#_):not(#__) .rs-item:hover .rs-media:not(:hover) img.rs-shot,
html body [id^="rn-hp-rts-"]:not(#_):not(#__) .rs-item:focus-within:has(button.rs-dot:focus) .rs-media img.rs-shot{
  opacity:1 !important;
}

/* ============================================================================
   IN THE PRESS WAS WELDED TO THE FOOTER.

   Sharon, 9 September: "the press is literally attached to the footer, so it
   needs breathing room ... cushion at the end of all the logos of In the Press."

   The desktop rhythm block near the top of this file zeroes padding on every
   flat section and gives the gap as margin-TOP instead — which is the right
   model and works everywhere on the page except at the very bottom, because
   the last section has no following section to bring a margin of its own. The
   footer simply begins. So the one place the margin-top model cannot reach is
   the one place it broke, and the fix belongs to whichever section ends up last
   rather than to In the Press specifically.

   Given as padding rather than margin: the footer's dark ground would collapse
   an adjoining margin against it in some engines, and padding inside a section
   standing on the page tone is guaranteed to render as the gap Sharon asked
   for. 96px, matching the rhythm's own larger step.
   ============================================================================ */
@media(min-width:901px){
  html body [id^="rn-hp-press-"]:not(#_):not(#__){
    padding-bottom:96px !important;
  }
}

/* ============================================================================
   OUR PROMISE COMES OFF THE BLACK — MOVED OUT OF THIS FILE, 9 Sep 2026.

   The beige treatment for [id^="rn-hp-promise-"] used to live here. It moved to
   assets/rn-theme-repairs.css when Sharon asked for the same strip at the foot
   of the PDPs: this file is loaded ONLY on the index template, so the strip
   would have rendered beige on the homepage and charcoal everywhere else.

   Do not re-add it here. See the block of the same name in rn-theme-repairs.css.
   ============================================================================ */

/* ============================================================================
   A CHOSEN COLOURWAY OUTRANKS THE ROOM SHOT.

   Sharon, 9 September: Ophelia's swatches change the picture; Diane's and
   Reya's are "super delayed ... very glitchy ... not working."

   They were neither. Ophelia carries NO staged scene photograph and Diane and
   Reya both do — and the same split exists in Ready Sooner Than You Think,
   which is why that section looked fine when Ophelia was the card tested. The
   swap fired instantly every time. But moving onto the photograph to look at
   the new colour is exactly what reveals the room shot, so the answer was
   covered the moment she went to read it. Twenty seconds of hovering could
   never show it; only leaving the picture would.

   The scene is one room photograph per PRODUCT and does not vary with fabric,
   so it cannot answer "what does this colourway look like". Once that question
   has been asked, the product shot wins. assets/rn-mobile-card-marketing.js
   puts `is-picking` on the card when a swatch is clicked and takes it off when
   the pointer leaves, so the hover reveal is kept — it just stops painting over
   a selection the customer made a moment ago.
   ============================================================================ */
html body [id^="rn-hp-cards-"]:not(#_):not(#__) .hp-card.is-picking .hp-media img.hp-scene{
  opacity:0 !important;
}
html body [id^="rn-hp-cards-"]:not(#_):not(#__) .hp-card.is-picking .hp-media img.hp-shot{
  opacity:1 !important;
}
html body [id^="rn-hp-rts-"]:not(#_):not(#__) .rs-item.is-picking .rs-media img.rs-scene{
  opacity:0 !important;
}
html body [id^="rn-hp-rts-"]:not(#_):not(#__) .rs-item.is-picking .rs-media img.rs-shot{
  opacity:1 !important;
}