/**
 * Small-player control bar (first-party companion to plyr.css).
 *
 * Plyr's control bar is a single no-wrap flex row sized for a full-width player.
 * In a small player -- a gallery thumbnail, a card, a phone -- it runs out of
 * room and pushes its LEADING items out of view: measured on a 234px player the
 * play button sat at -42px and the progress bar had collapsed to 3px, while the
 * volume slider (80px) and picture-in-picture were both still fully visible.
 * Exactly the wrong things survive.
 *
 * These queries drop the optional controls, smallest player first, so the
 * essential ones keep the width. They are keyed to the PLAYER's own inline size
 * rather than the viewport, so a 300px player inside a wide multi-column grid is
 * handled the same as one on a phone. Fullscreen needs no special case: the
 * player is wide there, so neither query matches.
 */

.plyr {
	container-type: inline-size;
	container-name: vgb-plyr;
	/* Plyr floors itself at min-width: 200px. In a smaller box -- a card, a
	   thumbnail, a step in a narrow accordion -- the player then overflows its
	   container and, wherever that container clips, the control bar is simply
	   cut off (measured: a 200x112 player in a 154x87 stage, 46px and 83px
	   outside it). The tiers below keep the controls usable instead. */
	min-width: 0;
}

/* The settings menu opens upward from the control bar and is not capped by Plyr,
   so on a card-sized player it is taller than the player itself: a 321px speed
   list in a 218px frame put its first entries (0.5x, 0.75x, Normal) above the
   top edge, where the block's own overflow clipped them away. There is no way to
   scroll to them either, because nothing was scrollable.

   Cap it to what actually fits and let it scroll. `cqw` resolves against .plyr
   (the container declared above), so the cap tracks the player's real size:
   width x 9/16 approximates the height of the common 16:9 case, less the control
   bar. Portrait players get a conservative cap, which is harmless now that the
   list scrolls. The floor keeps a couple of rows visible on tiny players, and the
   vh ceiling stops a very large player growing a full-page menu. */
.plyr__menu__container {
	max-height: min(60vh, max(112px, calc(100cqw * 0.5625 - 3.25rem)));
	/* Fallback only, for the moment before the script measures the player. It
	   decides whether scrolling is needed at all — see fitSettingsMenu — because
	   a permanent `auto` here puts a scrollbar on a one-row menu. */
	overflow-y: auto;
	overscroll-behavior: contain;

	/* A default platform scrollbar is ~17px of grey with stepper arrows, which
	   is wider than the menu's own padding and looks nothing like the player.
	   Thin translucent thumb, no track, no arrows. */
	scrollbar-width: thin;
	scrollbar-color: rgba(0, 0, 0, 0.32) transparent;
}

.plyr__menu__container::-webkit-scrollbar {
	width: 6px;
}

.plyr__menu__container::-webkit-scrollbar-track {
	background: transparent;
}

.plyr__menu__container::-webkit-scrollbar-thumb {
	background: rgba(0, 0, 0, 0.28);
	border-radius: 999px;
}

.plyr__menu__container::-webkit-scrollbar-thumb:hover {
	background: rgba(0, 0, 0, 0.45);
}

/* The stepper arrows at each end — the boxed triangles in the default bar. */
.plyr__menu__container::-webkit-scrollbar-button {
	display: none;
	height: 0;
	width: 0;
}

/* First to go: the volume slider (the mute button stays), PiP and AirPlay. */
@container vgb-plyr (max-width: 480px) {
	.plyr__controls .plyr__volume {
		flex: 0 0 auto;
		min-width: 0;
		width: auto;
	}

	.plyr__controls .plyr__volume input[type="range"],
	.plyr__controls [data-plyr="pip"],
	.plyr__controls [data-plyr="airplay"] {
		display: none;
	}

	.plyr__controls .plyr__progress__container {
		flex: 1 1 auto;
		min-width: 0;
	}
}

/* Then the time readout. It goes before the settings menu: the elapsed time is
   a nicety, while the menu is the only route to speed, quality and captions —
   dropping that first made those options simply unavailable on a card-sized
   player, which is where most of these blocks put one. */
@container vgb-plyr (max-width: 380px) {
	.plyr__controls .plyr__time {
		display: none;
	}
}

/* Only now the settings menu, and only because at this width there is no room
   left for it. Still reachable by going fullscreen, where every control
   returns. */
@container vgb-plyr (max-width: 300px) {
	.plyr__controls .plyr__menu {
		display: none;
	}
}

/* Below this the progress bar is down to ~20px — too small to scrub and easy to
   mis-tap. Drop it and keep three full-size controls: play, mute, fullscreen
   (fullscreen being the way back to the complete bar). */
@container vgb-plyr (max-width: 200px) {
	.plyr__controls .plyr__progress__container {
		display: none;
	}
}

/**
 * Frame clipping for provider embeds (YouTube / Vimeo).
 *
 * A YouTube or Vimeo player is an <iframe>, and an iframe is never clipped by a
 * border-radius on an ancestor -- only by `overflow` on the box that has the
 * radius. Plyr also scales and translates the provider iframe to crop the
 * letterboxing its embeds ship with, which pushes the iframe past the player's
 * edges by design. Together those produce the two artefacts you see on a rounded
 * player: square iframe corners sitting proud of the rounded frame, and video
 * bleeding outside it.
 *
 * A self-hosted <video> has neither problem, which is why this only shows up on
 * YouTube and Vimeo.
 *
 * The radius is chained down with `inherit` so each block keeps whatever radius
 * its own settings emit -- nothing is hardcoded here. `overflow: hidden` goes on
 * the wrappers that actually contain the iframe, and deliberately NOT on `.plyr`
 * itself: the settings menu pops out above the control bar and clipping there
 * would cut it off.
 */
.plyr {
	border-radius: inherit;
}

.plyr__video-wrapper,
.plyr__video-embed {
	border-radius: inherit;
	overflow: hidden;
}

/* The poster and the provider iframe are the two things that actually paint into
   the corners. */
.plyr__poster {
	border-radius: inherit;
}

.plyr__video-wrapper iframe,
.plyr__video-embed iframe {
	border-radius: inherit;
}

/* The player wrapper PlyrPlayer renders, whatever block hosts it. Blocks put
   their radius on the tile/frame ABOVE this element, and `inherit` only copies
   the immediate parent — so without this the chain dies here and the provider
   iframe renders square inside a rounded tile. No `overflow` on purpose: the
   settings menu can stand taller than the player, and the clipping that matters
   is already on .plyr__video-wrapper / .plyr__video-embed above. */
.bpl-plyr-host {
	border-radius: inherit;
}

/**
 * Fill mode — `cover` on PlyrPlayer.
 *
 * Plyr builds its own 16:9 box: `.plyr__video-embed` (and `--fixed-ratio`) use
 * `height: 0` with `padding-bottom: 56.25%`. Inside a frame that is a DIFFERENT
 * shape — a card with `aspect-ratio: 4 / 3`, a 1:1 tile, a fixed-height player —
 * the video therefore keeps its 16:9 shape and leaves black bands above and below
 * plus dead space in the frame, instead of taking the space it was given.
 *
 * Neutralising that padding box makes the player fill its host.
 *
 * Scoped to the `--cover` modifier deliberately, NOT applied to every player:
 * where a host has auto height it is Plyr's padding box that GIVES the player its
 * height, so removing it there would collapse the video to nothing. A block opts
 * in by passing `cover`, which is what that prop has always meant.
 */
.bpl-plyr-host--cover,
.bpl-plyr-host--cover .plyr,
.bpl-plyr-host--cover .plyr__video-wrapper,
.bpl-plyr-host--cover .plyr__video-embed {
	height: 100%;
	padding-bottom: 0;
}

/* Crop rather than letterbox — the point of "cover". */
.bpl-plyr-host--cover video {
	height: 100%;
	object-fit: cover;
}

/* A provider iframe has no intrinsic size, so it needs positioning to fill — and
   `object-fit` cannot crop it, because that only applies to replaced content the
   browser paints, never to a nested browsing context. So do `cover` with layout:
   keep the embed's own 16:9, make it at least as large as the host on BOTH axes,
   centre it, and let the host's `overflow: hidden` trim the overhang.

   This used to be `inset: 0; width: 100%; height: 100%`, which was wrong twice
   over. It stretched the iframe to the host box, so a 9:16 card got a 9:16 iframe
   and YouTube letterboxed the video inside it — the frame was full but the picture
   still had bands, i.e. not "cover" at all. And it collided with the blocks that
   centre the embed themselves: identical specificity (0,2,1) meant this sheet won
   `top`/`left` (→ 0) while their `translate(-50%, -50%)` still applied unopposed,
   dragging the video half its own width left and half its height up. Measured on
   the swipe deck: computed `top: 0` with `matrix(1,0,0,1,-180,-101.25)`.

   Centring here rather than in each block keeps one owner for the geometry.

   The ratio is the SOURCE's, not a fixed 16:9. Pinning it to 16:9 fixed the
   letterboxing at the FRAME but left the identical bug at the SOURCE: the
   provider letterboxes inside the viewport it is handed, so a 4:3 upload in a
   16:9 iframe kept 73px pillarbox bars down both sides — frame full, picture not.
   `--bpl-video-ar` carries the ratio Plyr resolves from the provider API (see
   trackEmbedRatio in PlyrPlayer.js); 16:9 stands in until it lands, and for
   anything that never reports one. Bars baked into the frames are untouchable
   either way — a cinematic trailer uploaded as 16:9 reports 16:9. */
.bpl-plyr-host--cover .plyr__video-embed iframe {
	position: absolute;
	top: 50%;
	left: 50%;
	transform: translate(-50%, -50%);
	min-width: 100%;
	min-height: 100%;
	width: auto;
	height: auto;
	aspect-ratio: var(--bpl-video-ar, 16 / 9);
}