/**
 * Component — ProgressBar
 *
 * Expected HTML (unchanged — .ec-progress-bar__canvas is created by
 * progress-bar.js at runtime, never authored):
 *   Determinate:
 *     <div class="ec-progress-bar" data-material="water" role="progressbar"
 *          data-ec-component="progress-bar"
 *          aria-valuenow="60" aria-valuemin="0" aria-valuemax="100">
 *       <div class="ec-progress-bar__fill" style="width: 60%"></div>
 *     </div>
 *   Indeterminate:
 *     <div class="ec-progress-bar ec-progress-bar--indeterminate" data-material="water" role="progressbar">
 *       <div class="ec-progress-bar__fill"></div>
 *     </div>
 *
 * Eleventh pass (motion-philosophy.md, "material simulation, not
 * decorative animation"): everything that used to fake movement with
 * CSS — the travelling-shine gradients, the pulsing turbulence
 * blobs, the blurred meniscus wobble, the DOM bubbles animating along
 * an authored @keyframes path — is gone. progress-bar.js now runs a
 * real per-frame bubble simulation on a <canvas>; see that file's
 * header comment for what's actually being computed each frame
 * (velocity mean-reverting toward a flow target, proximity-based
 * merging, fizz shedding, edge turbulence as elevated simulation
 * parameters rather than a separate effect). This file's job shrank
 * to three things: the pipe (untouched — "the pipe already looks good,
 * do not redesign it"), the flat water-colour body (.ec-progress-bar__fill,
 * still a real element so JS has something to read the target
 * percentage from and something for the canvas to size against — see
 * progress-bar.js), and canvas positioning.
 *
 * The fill's own width is set by JS every frame during the entrance
 * tween (not a CSS transition — the simulation needs to know the
 * exact current edge position every frame to clip and spawn against),
 * so this file deliberately does not declare `transition: width` on
 * `.ec-progress-bar__fill` any more.
 *
 * Twelfth pass (fidelity, not architecture): the colour read as deeper
 * Caribbean/open-ocean water rather than shallow tropical lagoon —
 * moved brighter and cleaner, and the fill is now fully opaque rather
 * than 95% colour-mix. "Do not make the water translucent" and "must
 * remain visible on every display, including lower-quality desktop
 * monitors" both rule out relying on any transparency for the
 * crystal-clear read; that read now comes entirely from the bubble
 * simulation and the pipe's own glass cues (::before below), not from
 * seeing through the water itself.
 */

:root {
	--ec-progress-bar-height: 1.25rem;
	--ec-progress-bar-loop-duration: 1.4s;
	--ec-progress-bar-fill-duration: 1400ms;
	--ec-progress-bar-water-color: #00b2e8;
}

@media (prefers-reduced-motion: reduce) {
	:root {
		--ec-progress-bar-fill-duration: 1ms;
	}
}

.ec-progress-bar {
	position: relative;
	overflow: hidden;
	width: 100%;
	height: var(--ec-progress-bar-height);
	border-radius: var(--ec-radius-full);
	background-color: rgba(255, 255, 255, 0.12);
	box-shadow:
		inset 0 2px 4px rgba(15, 23, 42, 0.1),
		inset 0 1px 0 rgba(255, 255, 255, 0.5);
	border: 1px solid rgba(180, 205, 210, 0.4);
}

/* The tube's glass walls — two soft static vertical highlights, not
   animated. A physical cue (light catching curved acrylic), not a
   decorative sweep. Untouched this pass — the pipe already looks
   right. */
.ec-progress-bar::before {
	content: '';
	position: absolute;
	inset: 0;
	background-image:
		linear-gradient(90deg, rgba(255, 255, 255, 0.55) 0%, transparent 6%),
		linear-gradient(270deg, rgba(255, 255, 255, 0.35) 0%, transparent 6%);
	pointer-events: none;
}

.ec-progress-bar__fill {
	position: relative;
	height: 100%;
	border-radius: var(--ec-radius-full);
	background-color: var(--ec-progress-bar-water-color);
	box-shadow:
		inset 0 1px 1px rgba(255, 255, 255, 0.3),
		inset 0 -1px 2px rgba(0, 0, 0, 0.1);
	overflow: hidden;
}

/* Nineteenth pass: once progress-bar.js is running, it paints the cap
   itself on canvas using the same deforming surfacePoints geometry as
   the surface simulation, so the DOM fill's own rounded right corner
   would just sit underneath as a second, static, undeformable edge.
   Flattened only once JS has taken over (.ec-progress-bar--js-cap,
   added by progress-bar.js) — indeterminate bars never get that class
   and keep their normal CSS-only rounded pill. */
.ec-progress-bar--js-cap .ec-progress-bar__fill {
	border-top-right-radius: 0;
	border-bottom-right-radius: 0;
}

/* The bubble simulation's canvas. Sized to the track's full bounds
   (not the fill's — the fill's width changes every frame during the
   entrance tween, and resizing a canvas's pixel buffer that often
   would be wasteful and would clear it); progress-bar.js clips
   drawing to the current fill width in JS instead. */
.ec-progress-bar__canvas {
	position: absolute;
	inset: 0;
	pointer-events: none;
}

.ec-progress-bar--indeterminate .ec-progress-bar__fill {
	position: absolute;
	width: 40%;
	animation: ec-progress-bar-indeterminate var(--ec-progress-bar-loop-duration) var(--ec-ease-standard) infinite;
}

@keyframes ec-progress-bar-indeterminate {
	0% {
		left: -40%;
	}

	100% {
		left: 100%;
	}
}

@media (prefers-reduced-motion: reduce) {
	.ec-progress-bar--indeterminate .ec-progress-bar__fill {
		animation: none;
		left: 0;
		width: 100%;
		opacity: 0.6;
	}
}