/* Band spacing for pages whose composer stacks its bands flush.
   Written for /de/ki/juno (Figma JTL-Website-Modules, page node 6918:492) and
   since shared by /de/greyhound-basic-preise, which carries the same two marker
   classes. Nothing here is keyed to either page — the markers are, which is why
   a second page could adopt it without a line changing. The filename still
   names juno only because renaming a loaded sheet is its own pass; it is really
   a component sheet.

   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;
  }
}

/* A smaller TOP-only band pad, for the first band under the breadcrumb.

   Page 10 (Account / Portal) is the first user. Its hero is the page's opening
   band: the design puts 48px between the breadcrumb and the overline, and ends
   the hero flush at the bottom because the login band below it owns the 80px
   between them. So the row carries this together with .jtl-band-flush, which
   zeroes the container's own 4rem on both edges, and the 48 is reasserted here
   on the section — where it does not have to win a specificity fight with the
   theme's container padding at all.

   The two steps down mirror .jtl-band-pad's proportions, and 32px on phones is
   what the band already had there before this class existed. */
.jtl-band-pad-top-sm {
  padding-top: 48px;
}

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

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

/* "KI im E-Commerce" band (ki-text-media-1): the square media renders small in
   the split-text-wide column (max 528px) with a big 144px gap and 64px side
   padding, leaving a lot of empty space beside and below it. On desktop, drop
   the inner side padding, tighten the gap, and widen the media column so the
   square image grows and fills that space. Marker-scoped (only rows the juno
   composer writes carry ki-text-media-1); left untouched below the widget's own
   992px stacking breakpoint, where the media is already full-width. */
@media (min-width: 993px) {
  .ki-text-media-1 .jtl-text-media__inner {
    padding-left: 0;
    padding-right: 0;
    gap: 80px;
  }
  .ki-text-media-1 .jtl-text-media__media {
    flex: 0 0 720px;
    max-width: 720px;
  }
}