/* Report-page integration for the chatbot's entity-chat affordances.
 *
 * The component's own stylesheet is the chatbot's file, served through /shared-chat and
 * loaded just before this one. It is read-only from here by design (same reason we don't
 * copy the js), so everything this page needs to say about it lives in this file. */


/* ------------------------------------------------------------------
 * Stacking.
 *
 * Two stacks were designed independently and collide. Ours (landing.css / report.css):
 * FAB 60, mobile TOC 70, mobile nav overlay 90, fixed header 100 (inner 101), reading
 * progress bar 110. The component's: pill 95, info card 96, drawer 100.
 *
 * Three real defects fall out of that, none of them cosmetic:
 *   - the drawer TIES with the fixed header at 100. It currently wins only because it is
 *     appended to <body> after .landing — a DOM-order accident, not a decision.
 *   - the pill (95) and card (96) sit UNDER the header, so selecting a line near the top
 *     of the viewport puts the button behind the nav where it cannot be clicked.
 *   - the progress bar (110) paints OVER the open drawer.
 *
 * So re-seat all three above 110, keeping the component's internal order intact.
 *
 * There is no `.ec-backdrop` rule here any more: the component dropped its scrim when the
 * drawer changed from covering the page to pushing it aside (see the drawer section of
 * css/entity-chat.css). A z-index on an element that is never created is dead weight that
 * reads as a live part of the stack, so it is gone rather than left "just in case".
 * ------------------------------------------------------------------ */
.ec-ask-pill  { z-index: 125; }
.ec-info-card { z-index: 126; }
.ec-drawer    { z-index: 130; }


/* ------------------------------------------------------------------
 * Nothing here re-anchors our fixed chrome any more, and that is the point.
 *
 * The widget used to be a full-height panel that pushed this page aside with
 * `padding-right: var(--ec-w)` on <body>. Body padding reflows normal-flow content but
 * CANNOT move `position: fixed` elements — they lay out against the viewport — so our two
 * (.lp-nav, pinned right: 0 and full-width, and .rp-progress) kept their full width and ran
 * underneath the panel: nav links hidden behind it, a reading-progress bar measuring a width
 * the reader could no longer see. This file had to re-anchor both to the same --ec-w, kill
 * their transitions mid-drag to stay flush, and scope all of it above 900px.
 *
 * The widget is now a small floating window in the bottom-right corner that reflows nothing,
 * so none of that compensation has anything to compensate for. Deleted rather than left
 * inert: a rule keyed on `body:has(.ec-drawer.open)` reads as live coupling between the two
 * apps, and the next person would have to work out that it no longer does anything.
 *
 * The z-index seating above is still needed — the window still has to sit above this page's
 * fixed header (100) and reading-progress bar (110).
 * ------------------------------------------------------------------ */


/* The hero is dark and its company name is brand orange (.accent). The component's
   `.ec-entity:hover { color: var(--text, #0A0A0A) }` would paint it near-black on that
   ground — i.e. the name vanishes on hover, the opposite of signalling affordance. Hold
   the inherited colour and let the hover chip do the signalling, which is its job. */
.rp-hero .ec-entity:hover,
.rp-hero .ec-entity:focus-visible { color: inherit; }


/* Hide the page's own chatbot FAB while the drawer is open — it is a second "open the
   chatbot" affordance sitting next to an already-open chatbot. (It used to also show
   through dimmed under the component's backdrop at z 60; that scrim is gone now, but the
   duplicate-affordance reason stands on its own.) Mirrors the component's rule for its own
   .ec-fab launcher (which a page using this FAB instead never mounts).

   opacity/visibility rather than `display`, so it uses the same mechanism as report.js's
   `.is-hidden` scroll toggle and the two can't fight over the same property. */
body:has(.ec-drawer.open) .rp-chatbot-fab {
  opacity: 0;
  visibility: hidden;
  pointer-events: none;
}


/* ------------------------------------------------------------------
 * The floating chatbot launcher image button.
 *
 * Moved here from report.css (was report-page-only) so any page loading this file --
 * the company report itself, plus the companies list ("Reports") and stories list
 * ("Insights") pages, which pass launcher=false to chatbot_widget_config() and use this
 * instead of the component's own circular .ec-fab -- can share one look. Not in the
 * original reference design; a user request.
 *
 * Fixed rather than sticky: it needs to float at a viewport corner across several
 * unrelated sections, which a single position:sticky containing block can't span. On the
 * company report page report.js additionally toggles `.is-hidden` from scroll position to
 * confine it to a hero-to-CTA range; pages that don't load report.js simply never add that
 * class, so the button stays always-visible there, same as the component's own .ec-fab.
 *
 * z-index 60 is deliberate: under the fixed header's 100 (landing.css) so the nav still
 * wins if they ever overlap, but above ordinary page content.
 * ------------------------------------------------------------------ */
.rp-chatbot-fab {
  --fab-size: 64px;
  --fab-inset: 40px;
  position: fixed;
  /* env() falls back to 0px on devices with no inset (the safe-area-inset-*
     keywords are only non-zero behind a notch/home-indicator/gesture bar), so
     this is a no-op everywhere except where that hardware actually intrudes —
     without it, a fixed bottom-right circle can render partly behind that
     chrome on iOS Safari and read as clipped/overflowing. */
  right: calc(var(--fab-inset) + env(safe-area-inset-right, 0px));
  bottom: calc(var(--fab-inset) + env(safe-area-inset-bottom, 0px));
  z-index: 99;
  display: flex;
  width: var(--fab-size);
  height: var(--fab-size);
  border-radius: 50%;
  overflow: hidden;
  transition: opacity 0.25s ease, visibility 0.25s ease, transform 0.2s ease;
}
@media (max-width: 1024px) { .rp-chatbot-fab { --fab-size: 64px; --fab-inset: 28px; } }
@media (max-width: 767px)  { .rp-chatbot-fab { --fab-size: 64px; --fab-inset: 20px; } }
@media (max-width: 479px)  { .rp-chatbot-fab { --fab-size: 56px; --fab-inset: 16px; } }
.rp-chatbot-fab img {
  width: 100%;
  height: 100%;
  object-fit: cover;
  display: block;
}
/* Same hover nudge convention as .rp-external-link on the report page. */
.rp-chatbot-fab:hover, .rp-chatbot-fab:focus-visible { transform: scale(1.06); }
/* Applied by report.js, not by CSS alone — see the rule comment above for why this can't
   just be position:sticky. Hidden via opacity+visibility rather than display:none so the
   transition can animate and so no-JS visitors, for whom this class is never added,
   always get the plain visible link. Pages without report.js never add this class, so it
   is dead weight there, not a bug — the button simply stays visible. */
.rp-chatbot-fab.is-hidden {
  opacity: 0;
  visibility: hidden;
  pointer-events: none;
}