/*
 * UX KIT STYLES — the paint for public/javascripts/ui.js: loading skeletons,
 * tooltips, and the wrapper that lets a disabled button have one.
 *
 * ⚠ ITS OWN FILE, NOT PART OF theme.css, AND THAT IS THE POINT. theme.css is
 * the CUSTOMER surface's design system; the two admin pages (/ and /accounts)
 * deliberately do not load it — they are plain Bootstrap — and they need
 * skeletons and tooltips just as much. One file that goes everywhere is what
 * keeps loading and hovering feeling the same in all three places.
 *
 * ⚠ EVERY THEME TOKEN IS USED WITH A FALLBACK, for the same reason: on the
 * admin pages none of them is defined. `var(--ink-raised, #2f2a25)` renders the
 * themed colour where theme.css is loaded and the literal everywhere else.
 * Never reach for a token here without one.
 */

/* =====================================================================
   Loading skeletons (UX.Skeleton)

   GREY PLACEHOLDER BARS IN THE SHAPE OF THE CONTENT, not a spinner. The
   difference is not decoration: a spinner is centred in an empty region, so
   when the data lands the whole page below it jumps. A skeleton occupies the
   space the real content will occupy, and the swap moves nothing.

   ⚠ THE BARS ARE NEUTRAL GREY, deliberately off the customer palette.
   Everything real there is cream and ink; a placeholder in --surface-sunk would
   read as a card that had finished loading and turned out to be empty. Grey
   reads as "not content yet" in a way no palette colour can.

   ⚠ NEVER PUT TEXT IN A SKELETON. ui.js marks every group aria-hidden and the
   region aria-busy, so assistive tech is told "this is updating" — the truth —
   instead of being read a row of empty boxes.
   ===================================================================== */
:root {
  --sk-base:  #e3e0da;
  --sk-shine: #f2f0ec;
}

.sk {
  display: block;
  background-color: var(--sk-base);
  /* The sweep is a moving highlight over the flat bar — one animation for the
     whole page, so twenty placeholders pulse as one surface. */
  background-image: linear-gradient(90deg, rgba(255, 255, 255, 0) 20%, var(--sk-shine) 50%, rgba(255, 255, 255, 0) 80%);
  background-size: 220% 100%;
  background-repeat: no-repeat;
  animation: sk-sweep 1.5s ease-in-out infinite;
  border-radius: var(--radius-sm, 6px);
}
.sk-bar    { height: .72rem; }
.sk-bar-lg { height: 1.05rem; }
.sk-pill   { height: 2.05rem; border-radius: 8px; }
.sk-circle { width: 10px; height: 10px; border-radius: 50%; }
.sk-group  { display: block; }
/* Stacked bars need air between them or they read as one grey block. */
.sk-group .sk + .sk { margin-top: .55rem; }
/* A skeleton row inside a table keeps the table's own cell padding. */
.sk-row td { vertical-align: middle; }

@keyframes sk-sweep {
  from { background-position: 140% 0; }
  to   { background-position: -40% 0; }
}

/* A STATIC grey bar is still a correct skeleton — the shape is the message and
   the shimmer is only alive-ness, so this drops the animation and keeps the
   layout. (theme.css kills transitions globally under the same query; an
   animation has to be named separately, and the admin pages have no such rule
   at all.) */
@media (prefers-reduced-motion: reduce) {
  .sk { animation: none; background-image: none; }
  /* The tooltip keeps its `fade` class in every mode — it is what hides the
     element until Popper has placed it (see ui.js) — so the reduced-motion
     answer is to collapse the fade, not to remove it. theme.css already does
     this globally on the customer surface; the admin pages do not load it. */
  .tooltip.ux-tip { transition-duration: .01ms; }
}

/* =====================================================================
   Tooltips (UX.Tips)

   Bootstrap's tooltip, dressed to match the app and pointed at the buttons
   whose only label is an icon.
   ===================================================================== */
/*
 * ⚠ A TOOLTIP IS NEVER A HOVER TARGET. Bootstrap 5.3 leaves `pointer-events`
 * at `auto`, so a tooltip that lands under the cursor — which is exactly what a
 * `placement: top` tooltip does when the pointer is near the top edge of its
 * button — takes the pointer, the button sees `mouseleave`, the tooltip hides,
 * the cursor is over the button again, and it reopens. It flickers for as long
 * as you hover. This one line ends it. (The other half of that trap is the
 * tooltip growing the document and raising a scrollbar; see the
 * `strategy: "fixed"` note in ui.js.)
 */
.tooltip.ux-tip { pointer-events: none; }

.tooltip.ux-tip {
  --bs-tooltip-bg: var(--ink-raised, #2f2a25);
  --bs-tooltip-color: #fff;
  --bs-tooltip-opacity: 1;          /* the default .9 lets the page bleed through the text */
  --bs-tooltip-border-radius: 8px;
  --bs-tooltip-font-size: var(--fs-sm, .8125rem);
  --bs-tooltip-padding-x: .6rem;
  --bs-tooltip-padding-y: .35rem;
  --bs-tooltip-max-width: 17rem;
}
.tooltip.ux-tip .tooltip-inner {
  font-family: var(--font-ui, inherit);
  font-weight: 500;
  line-height: 1.35;
  text-align: start;               /* left in English, right in Arabic — never centred prose */
  box-shadow: var(--shadow-pop, 0 4px 16px rgba(32, 29, 26, .10), 0 1px 3px rgba(32, 29, 26, .07));
}

/*
 * THE WRAPPER AROUND A CONTROL THAT CAN BE DISABLED. A disabled <button>
 * dispatches no pointer events, so the tooltip has to live on something else —
 * see the long note in ui.js. It must be invisible to the layout: inline-flex,
 * so a wrapped button is still a flex item of the same size, and no box of its
 * own. Bootstrap already sets `pointer-events: none` on a disabled .btn, which
 * is what lets the pointer reach this span.
 */
.tip-wrap { display: inline-flex; }
.tip-wrap > .btn { width: 100%; }

/*
 * ...AND INSIDE A .btn-group, where that wrapper would otherwise break the
 * seam. Bootstrap joins a group with `.btn-group > .btn` rules — square the
 * inner corners, pull each button one border-width left — and a wrapped button
 * is no longer a direct .btn child, so it springs back to fully rounded and the
 * group falls apart into separate buttons.
 *
 * These are the same three rules, re-aimed at the wrapper. They matter on the
 * orchestrator page, whose zoom controls are a group of icon buttons — which is
 * exactly the kind of button that needs a tooltip in the first place.
 */
.btn-group > .tip-wrap { position: relative; }
.btn-group > .tip-wrap:not(:first-child) { margin-left: calc(var(--bs-border-width, 1px) * -1); }
.btn-group > .tip-wrap:not(:last-child) > .btn {
  border-top-right-radius: 0; border-bottom-right-radius: 0;
}
.btn-group > .tip-wrap:not(:first-child) > .btn {
  border-top-left-radius: 0; border-bottom-left-radius: 0;
}