/* Band spacing for /de/ki/juno — Figma JTL-Website-Modules, page node 6918:492.
   (Filename is provisional and gets the JP key when the sub-task exists, same as
   the composer script.)

   The design stacks all thirteen bands FLUSH against one another, each carrying
   its own 80px of top and bottom space. Measured on every band frame: the gap
   between one band's bottom and the next band's top is 0.0 throughout.

   The theme gives every `section > .container` 4rem of its own vertical padding
   (app.css). On this page that lands BETWEEN the bands, on top of whatever the
   widget already carries — 128px per boundary that the design does not draw, and
   roughly a screen and a half of extra page height over twelve boundaries.

   Both classes below are written onto the row by the page's own composer
   (scripts/db/jp-juno-page/lib.php, ki_band_row()), through the pagebuilder's
   `advanced` param, which renders them on the section element. Only rows that
   composer writes carry them, so no other page can be reached by these rules —
   which is why this is scoped by a marker rather than by a page id (a page id
   would also match the page's WPML twin, and this page may yet gain one). */

/* Take back the container's own vertical padding: the band inside owns it.

   The selector is doing specificity arithmetic, not narrowing scope. Two rules
   have to be beaten, and the second one is why the class is repeated:

     section > .container                                  (0,1,1)  app.css, 4rem
     .page-template-product-landing main .container        (0,2,1)  the widget
       plugin's assets/style.css, inside @media (max-width: 767px), 2rem

   A bare `.jtl-band-flush > .container` is (0,2,0) and loses the second one
   outright — that is the bug where every band kept 32px top and bottom on phones
   while desktop looked right. Adding `main` makes it (0,2,1), which only TIES,
   leaving source order as the tiebreaker: it wins here because the clone loader
   enqueues overrides after the plugin, but the loader on the deployed boxes is a
   different file whose priority is not recorded anywhere. Repeating the class
   makes it (0,3,1) and the outcome independent of load order.

   Worth keeping in mind that this failure is invisible to a gap-between-bands
   measurement: the padding sits INSIDE each section box, so adjacent sections
   still touch and the gap still reads 0. */
main .jtl-band-flush.jtl-band-flush > .container {
  padding-top: 0;
  padding-bottom: 0;
}

/* The design's 80px band padding, for the bands whose widget carries none of its
   own. These widgets are transparent, so the space can sit on the row without a
   painted background being cut short — the full-bleed bands that DO paint keep
   their padding inside the widget, where the colour follows it. */
.jtl-band-pad {
  padding-top: 80px;
  padding-bottom: 80px;
}

@media (max-width: 992px) {
  .jtl-band-pad {
    padding-top: 64px;
    padding-bottom: 64px;
  }
}

@media (max-width: 768px) {
  .jtl-band-pad {
    padding-top: 48px;
    padding-bottom: 48px;
  }
}