/* The loading screen every demo shows before its own application takes over.
 *
 * Shared by all six .web projects through BrowserDemo.props, which links it into each
 * wwwroot/css/. Editing it here changes every demo; there is no per-demo copy.
 *
 * WHY A REAL PERCENTAGE AND NOT AN ANIMATION. The .NET runtime publishes its own download
 * progress as two CSS custom properties, --blazor-load-percentage and
 * --blazor-load-percentage-text, updating them as resources arrive. The bar below is driven
 * by those, so it tracks the actual download. An animated bar that did not would be a lie
 * about our own product told on the way into a page whose whole subject is honest numbers.
 *
 * THE BAR COVERS ALMOST THE WHOLE WAIT, WHICH IS WHY THERE IS NOTHING ELSE HERE. Measured
 * on the qubit demo with the cache ignored: 1,416 ms of runtime download against 161 ms of
 * device start-up afterwards, and at a 6x CPU slowdown 10,588 ms against 1,066 ms. So the
 * download is nine tenths of it in both cases, and the second phase happens with the
 * application already on screen and its controls disabled, which does not read as a frozen
 * page. Reporting named start-up steps was considered and dropped: it needs a mechanism in
 * each of the six demos and would cover about a second of eleven.
 *
 * .booting__step is left in the markup for whoever wants that second, and nothing writes to
 * it today. If something does, give it named steps rather than a percentage - no figure
 * exists for that phase, and inventing one is the thing this file exists to avoid.
 *
 * THE SPINNER IS NOT DECORATION. The runtime reports progress over resources, and compiling
 * WebAssembly can hold the bar near its last value while the CPU works. The spinner turns
 * throughout, so that stretch reads as a page still working rather than one that has died.
 */

.booting {
  display: flex;
  flex-direction: column;
  align-items: center;
  gap: 0.9rem;
  padding: 4rem 1.25rem;
  color: var(--muted, #57606a);
  font: 15px/1.5 system-ui, -apple-system, "Segoe UI", Roboto, sans-serif;
  text-align: center;
}

/* Spins the whole time, so a stalled download still looks like a page that is alive rather
   than one that has died. The bar says how far; this says whether anything is happening. */
.booting__spinner {
  width: 2.1rem;
  height: 2.1rem;
  border: 3px solid var(--line, #d0d7de);
  border-top-color: var(--accent, #1f6feb);
  border-radius: 50%;
  animation: booting-spin 0.9s linear infinite;
}

@keyframes booting-spin { to { transform: rotate(360deg); } }

@media (prefers-reduced-motion: reduce) {
  .booting__spinner { animation-duration: 3s; }
}

.booting__label { margin: 0; }

.booting__track {
  width: min(22rem, 80%);
  height: 6px;
  border-radius: 999px;
  background: var(--line, #d0d7de);
  overflow: hidden;
}

/* The one line that matters: the width IS the runtime's own figure. */
.booting__bar {
  height: 100%;
  width: var(--blazor-load-percentage, 0%);
  background: var(--accent, #1f6feb);
  border-radius: inherit;
  transition: width 0.15s ease-out;
}

/* Empty until the runtime has a figure, so a browser that never sets the property shows a
   spinner and a label rather than a stuck "0%". */
.booting__pct {
  font-variant-numeric: tabular-nums;
  font-size: 0.85rem;
}

.booting__pct::after { content: var(--blazor-load-percentage-text, ""); }

/* Written by the application once the runtime is up, one named step at a time. */
.booting__step {
  font-size: 0.85rem;
  min-height: 1.2em;
}

/* Start-up threw. Shown by the application; the runtime's own failure path is
   #blazor-error-ui, which is a different thing and stays as it was. */
.booting--failed .booting__spinner {
  animation: none;
  border-color: var(--bad, #b42318);
}

.booting--failed .booting__step { color: var(--bad, #b42318); }