` for `kind="video"`, an `` or `` for the file-chip fallback depending on href safety), `media` (the ``/ `` — only `http:`/`https:`/`blob:` (plus `data:` for a _media_ `src` only) or a scheme-relative/relative URL with no scheme at all pass; anything else (`javascript:`, `vbscript:`, and similarly suspicious schemes) is rejected. `data:` is allowed for a media source (a browser never executes script from a media element's `src`) but rejected by the stricter link validator (a `data:text/html` URI navigated to via a clicked `` runs as a full document and can execute script) — the same scheme gets a different verdict depending on which DOM sink it's headed for. Both validators delegate to the platform's own `new URL()` parser rather than a hand-rolled scheme regex, specifically because `new URL()` already implements the WHATWG URL Standard's input normalization (stripping tab/newline/leading-trailing space before looking for a scheme) — a naive regex is vulnerable to exactly the kind of tab-injected-into-a-scheme bypass a browser attribute sink still normalizes and executes. An `image`/`video` `kind` whose `src` fails the media-src check falls back to the generic file-chip rendering, which then separately re-validates `src` against the stricter href allowlist for its own download affordance. `kind="video"` renders its open affordance as a separate `[part="open-button"]` next to `[part="media"]` rather than wrapping the whole card in one `