/* ==========================================================================
   Block: Embedded portal
   ========================================================================== */

.awx-embed-frame__viewport {
  position: relative;
  width: 100%;
  height: var(--awx-embed-height, 80vh);
  overflow: hidden;
  /* White, not var(--surface-bg): the embedded page is a third party's
     and knows nothing about this site's theme. CAD Details' app leaves
     its own body background transparent, so in dark mode ours showed
     through and their near-black product headings rendered on navy —
     measured, not guessed. Giving the frame the light background its
     content was designed for is the only lever available from out here,
     since nothing inside a cross-origin frame can be styled. */
  background: var(--awx-white, #fff);
}

/* Full browser width, the same break-out media-text's overlap arrangement
   uses — an embedded catalog reads as a slab of the page rather than a
   column of it. The alternative leaves the frame inside the section's own
   inner, so it stops at the page gutter and the embedded site's margins
   nest inside this page's instead of running past them. The choice is not
   only cosmetic: the frame is the layout viewport for the document inside
   it, so it also picks which of their breakpoints renders. */
.awx-embed-frame__viewport--full {
  width: 100vw;
  margin-inline: calc(50% - 50vw);
}

/* Cropping from OUTSIDE is the only way to hide anything in the embedded
   page: it is cross-origin, so no stylesheet of ours reaches inside it.
   The frame is made taller than its window by both crops and then pulled
   up by the top one, so the visible band is the middle of a taller frame:
   the embedded site's header is clipped above it and their footer below.

   WHY THE TOP CROP WORKS. CAD Details' header is position: sticky with
   top: 0, and a sticky header pins to the top of its own layout viewport
   — which inside an iframe is the iframe element's box, not the part of
   it a visitor can see. So it stays inside the clipped band at every
   scroll position. A static header would behave the other way round,
   clipped at rest and then scrolling up out of the band for good. Either
   way it stays hidden. What WOULD defeat it is a header that re-enters on
   scroll: sticky with a non-zero top, or a show-on-scroll-up pattern.

   WHY THE BOTTOM CROP WORKS, which is a different argument. Nothing is
   permanently hidden down there: the band below the window is just
   below-the-fold content, and it scrolls up into view like any other.
   The footer is the exception because it is the LAST thing in the
   document — when their scroller reaches its end the footer sits at the
   bottom of the frame's own viewport, which is exactly the region the
   crop puts out of sight. So it is hidden at the one scroll position
   where it would otherwise appear, and costs nothing at the others.

   WHAT NEITHER CROP CAN DO. Scrolling past either end of their document
   rubber-bands it and pushes a cropped band briefly back into the
   window. Suppressing that needs overscroll-behavior on their document,
   which is cross-origin and unreachable. The crops carry a few pixels of
   slack past the measured heights, which makes a small bounce land
   harmlessly, but a hard flick will still show a sliver. That is a
   limitation to accept, not a bug to chase — the real fix is an embed or
   white-label view from the vendor, which Todd has asked them for.

   Measured, not taken from a screenshot: header.aspen-header is 96px and
   identical at 1440, 1248, 1024 and 375 (it is not responsive).
   footer.footer is 203px at 1440, 1248 and 1024, and 285px at 375 —
   responsive, but only below the width where this block hides the frame
   entirely, so 203 is the number that matters. */
.awx-embed-frame__frame {
  position: absolute;
  top: calc(var(--awx-embed-crop, 0px) * -1);
  left: 0;
  width: 100%;
  height: calc(
    var(--awx-embed-height, 80vh) + var(--awx-embed-crop, 0px) +
      var(--awx-embed-crop-bottom, 0px)
  );
  border: 0;
  display: block;
}

/* The link out sits under the embed at every width, because an embed is
   a preview and some people want the real thing in its own tab. */
.awx-embed-frame__fallback {
  margin-top: var(--awx-space-md);
  text-align: center;
}

.awx-embed-frame__fallback-body {
  margin-inline: auto;
  margin-bottom: var(--awx-space-sm);
}

/* Below 48rem the embed is replaced by that link rather than shrunk.
   A nested scroll region inside a scrolling page is a trap on a phone —
   their catalogue is ~4000px tall at 375 and the visitor would be
   dragging it through a window a few hundred pixels high, with no
   reliable way to tell which of the two surfaces a swipe will move.
   Their own site is responsive and is a better phone experience at full
   screen than at a fifth of one. Hiding the viewport also means the
   lazy frame never intersects anything, so the third-party app is not
   downloaded on mobile data at all. */
@media (max-width: 47.99rem) {
  .awx-embed-frame__viewport {
    display: none;
  }

  .awx-embed-frame__fallback {
    margin-top: 0;
  }
}