Clip

IT KEEPS ITS PLACE ON THE WAY INTO THE WINDOW, AND BACK

A clip with a lightbox is one piece of film in two video elements. Left alone they are strangers: the big one starts at zero however long you watched the small one, and the small one is still where it was when you close the window. x-ds-clip hands the position over on open and takes it back on close, so you land where you were. Measured both ways at 0.00s of drift.

It needs no attribute. A clip containing a [commandfor] that names a dialog with a video in it is the lightbox shape — there is nothing else it could be — and asking a caller to say so twice would be a second spelling of what the markup already says. It declines unless both elements are told to play the same file, because seeking an unrelated video to somebody else's timestamp is a worse bug than not syncing at all.

The page's copy stands down while the window is open. Two decoders on one film is battery a reader pays for, and they drift, so the hand back would jump.

🛑 A seek before the film has loaded is thrown away, which is the trap this cost an evening to find. These clips are preload="none", so the window's copy has readyState 0 when it opens. Setting currentTime then appears to work — the property reads the value back and keeps it — and then play() loads the resource and resets it to zero. So the seek waits for loadedmetadata when there is nothing loaded yet, and happens at once when there is.

A CLIP IN A LIGHTBOX HAS NO CONTROL, AND THAT IS CORRECT

Every clip on this page carries a pause, and the note above says why that is not optional. A clip inside a modal is the one place it comes off — not as an exception granted, but because the criterion has stopped applying. 2.2.2 governs motion presented in parallel with other content, and it is met by pause, stop or hide. A lightbox is neither half of that: the reader opened it on purpose, it fills the screen, and there is nothing beside it to be distracted from. It is the content.

And the mechanism is already there, three times over — modal-close, the veil, and Escape — by pointer, by keyboard and by touch. The clip is muted throughout, so audio control never enters into it. What you gain is the picture: a plate is a cream square with a shadow lying in the middle of the only thing the window was opened to show. Look at the lightbox on the modal page — its clip is bare.

Anywhere the reader did not ask for the window, none of this applies and the pause is owed.

ITS BORDER DOES NOT ANSWER A POINTER

Every other toggle takes its border to the accent on hover. A tab cannot: three of its sides would light up and the fourth could not follow, because the fourth is the frame's border and a component does not reach into its neighbour. What that draws is an accent U with a gap in it, which reads as a rendering fault rather than as a hover.

So the glyph and the fill carry it instead — which is the honest place for it here anyway. The tab is pretending to be part of the picture's outline, and an outline that changes colour when a pointer passes has stopped pretending. Focus shows the same pair plus the ring, because a keyboard user should see exactly what a pointer user sees.

IT BORROWS THE FRAME'S BORDER AND THE FRAME'S CORNER

--ds-rule and --ds-radius-frame, not --ds-rule-strong and --ds-radius-control, because a tab is pretending to be part of the picture's outline rather than a button standing near it. The merged edge carries no border at all — the frame's own is the shared line, and a second one there is the two-pixel rule this design never has.

--ds-radius-frame exists so that "matches the picture" is true by construction rather than by coincidence. Frames are square today; the day a theme rounds them, the tab rounds with them instead of going on being a 5px control corner beside a rounded photograph.

Which is exactly why a tab hanging under something that is not a picture needs to say so. clip-hang-panel on the wrapper swaps the media corner for --ds-radius, the one every other box in the system reads. You can see the difference on this page: the theme you are reading squares its frames at 0px and rounds everything else at 5px, so without that class the tab under the mesh above would go square while the mesh stayed round. The wrapper says it because the wrapper is the only thing that knows what is inside it.

WITHOUT JAVASCRIPT IT IS A PICTURE

The markup carries controls and the button ships hidden. With no script the reader gets the poster and the browser's own play button, and zero video bytes are fetched — which is precisely the still image this component replaces, not a degraded version of anything. x-ds-clip swaps them over: it removes controls and reveals ours. A control that cannot work is never on screen, in either direction.

MAKING THE THREE FILES

The clip above is this recipe's own output — 5.3 kB of webm, 8.3 kB of mp4 and a 1.7 kB poster, for four seconds at 960×540. Three of these flags are doing unobvious work and all three matter.

# 1 · the webm — smaller, and the browser tries it first
ffmpeg -i source.mov \
  -c:v libvpx-vp9 -crf 38 -b:v 0 -row-mt 1 \
  -pix_fmt yuv420p -an  clip.webm

# 2 · the mp4 — the one that plays everywhere
ffmpeg -i source.mov \
  -c:v libx264 -crf 30 -preset slow \
  -pix_fmt yuv420p -movflags +faststart -an  clip.mp4

# 3 · the poster — frame zero, so playback does not jump when it starts
ffmpeg -i source.mov -vf "select=eq(n\,0)" -frames:v 1 \
  -c:v libsvtav1 -crf 30  clip.avif

• -an strips the audio track entirely. muted only silences playback — a muted clip with a track still ships those bytes, and a track that does not exist can never be un-muted by a stray script.
• -movflags +faststart moves the mp4's index to the front. Without it the browser must fetch the end of the file before it can begin, which on a lazily-loaded clip is a stall exactly where nobody is watching for it.
• -pix_fmt yuv420p — anything else fails to decode on Safari, silently, on the one browser you are least likely to be testing in.

Take the poster from frame zero rather than a nice-looking frame further in, so that the moment playback starts there is no jump. And keep the loop seamless — if the last frame does not match the first, the join is the only thing anybody will see.

TWO ASPECT RATIOS

There is no declarative way to do this any more. <source media> was removed from the HTML specification in 2014; Chrome and Firefox dropped it and only Safari kept it, so a media query inside a <video> works on one browser and is ignored by the rest. Nothing here pretends otherwise.

What works is two clips and one hidden — and because both carry preload="none", the hidden one costs nothing beyond its own poster, which loading="lazy" also defers. Set --ratio per instance on each .frame, exactly as a picture does, and let the consuming page decide which is shown. That is a page-level decision about content, and the library does not have an opinion about it.

WHAT THIS IS NOT

Not a video player: no sound, no scrubbing, no fullscreen, no captions. A clip with dialogue in it is a different component with different obligations, and reaching for this one there produces something that cannot be paused anywhere useful and cannot be understood without hearing it. Not a background hero either — it sits in a .frame with a stated ratio, so it cannot become full-bleed motion behind text.