Last updated: October 30, 2026.
This document links developer needs and supporting evidence to the revised Image Preview proposal.
The main proposal covers preview, previewset, and their reflected properties, including responsive previews and art direction. Styling and reveal control are independent proposals sketched in the explainer's appendix.
Image Preview does not define compact formats or their encoding and decoding algorithms. These require separate specifications; blurhash("...") is illustrative syntax.
The research combines public standards discussions reviewed on October 28, 2026, existing preview implementations, and anonymized internal partner feedback.
The sources establish needs and constraints, not API consensus or universal user benefit.
| ID | Developer need | Proposal disposition |
|---|---|---|
| DN-01 | Reduce custom preview lifecycle code | Main proposal |
| DN-02 | Choose an appropriate presentation, including no preview | Main proposal |
| DN-03 | Use lightweight representations and existing asset pipelines | Main proposal |
| DN-04 | Keep previews aligned with responsive images and art direction | Main proposal |
| DN-05 | Control loading cost without delaying important content | Invariant; independent loading open |
| DN-06 | Enable previews selectively on the client | Main proposal; browser-managed rules open |
| DN-07 | Show waiting content before a preview is available | Styling |
| DN-08 | Style image pixels with correct geometry and compositing | Invariant; Styling for customization |
| DN-09 | Customize activity feedback and transitions | Styling |
| DN-10 | Control progressive versus complete-frame presentation | Reveal |
| DN-11 | Handle repeated image replacement | Main proposal; replacement presentation and transitions open |
| DN-12 | Preserve image semantics, layout, and accessibility | Invariant |
| DN-13 | Observe and measure meaningful loading milestones | Open |
| DN-14 | Retain predictable fallback and platform protections | Invariant |
Need. Replace per-component code for preview display, image loading, replacement, source changes, cancellation, and cleanup.
Evidence. whatwg/html#3631 and whatwg/html#2806 discuss native loading and placeholder behavior. Existing implementations and partner feedback identify the cost of managing this lifecycle in script.
Proposal response. The browser manages previews without changing main-image selection or the meaning of existing image APIs.
Need. Choose whether a preview is useful for the content and, if so, whether to use a recognizable thumbnail, an abstract representation, or a color.
Evidence. MicrosoftEdge/MSEdgeExplainers#1401, MicrosoftEdge/MSEdgeExplainers#1406, and MicrosoftEdge/MSEdgeExplainers#1407 question preview usefulness and compare alternatives. Partner feedback requests choice and experimentation.
Proposal response. Authors choose whether to provide a preview and which representation to use. Previews complement progressive delivery rather than replace it.
Need. Keep previews inexpensive to transfer and decode, and reuse preview data already generated for web and native apps, including data embedded in HTML or API responses.
Evidence. whatwg/html#3631 requests several input types; MicrosoftEdge/MSEdgeExplainers#1406 discusses quality-per-byte and format costs. Partner feedback adds compact response payloads and shared-pipeline compatibility.
Proposal response. preview accepts URLs, compact representations, and colors, allowing authors to reuse existing preview data.
Need. Match the preview to the selected image across different crops, subjects, resolutions, and color-scheme variants.
Evidence. whatwg/html#3631 requests <img> and <source> support. MicrosoftEdge/MSEdgeExplainers#1402 raises art direction and light-preview flashes before dark-mode content.
Proposal response. preview associates content with the selected <img> or <source> branch; previewset adds density-based candidates. A dark-mode source can supply its own preview without falling back to a shared light preview.
Need. Avoid delaying selected-image discovery or requests, and control the cost of previews, including those shown before lazy-loaded images.
Evidence. MicrosoftEdge/MSEdgeExplainers#1404 requests independent preview loading; whatwg/html#5408 discusses lazy-loading gaps; whatwg/html#1920 covers decoding and memory costs.
Proposal response. Preview work does not block main-image discovery or request creation, although extra requests can still compete for resources. Loading a preview ahead of its lazy-loaded main image remains an open question.
Need. Enable previews selectively based on client conditions and experiment with different loading experiences.
Evidence. Partner feedback requests client-side control. w3c/csswg-drafts#11691 requests low-bandwidth image placeholders and bandwidth-based image selection.
Proposal response. Authors can choose whether to provide a preview, including from script. Whether the browser should offer a built-in rule such as "use previews only on slow connections" remains open.
Need. Show useful initial content, such as an image-specific color, while preview data is unavailable. Even inline data can arrive late in a streamed document.
Evidence. whatwg/html#3631 and the 2014 CSS placeholder proposal discuss loading placeholders. Partner feedback explicitly requests waiting content before a preview arrives.
Proposal response. The styling appendix explores a placeholder part that works without preview data. A waiting background is separate from using a color as the preview itself.
Need. Blur image content without blurring its outer edges or borders, align temporary content with the image box, and replace transparent content without unintended overlap.
Evidence. w3c/csswg-drafts#3134, w3c/csswg-drafts#8243, and MicrosoftEdge/MSEdgeExplainers#1405 cover styling, geometry, and alpha-correct crossfading. Partner feedback requests sharp outer edges around blurred content.
Proposal response. The main proposal preserves sizing, clipping, and replacement. The styling appendix explores parts that can be styled separately and blended together without mixing with the page background.
Need. Provide optional, efficient activity feedback and transitions, with appearance, pace, and fade strength consistent with the site's other UI.
Evidence. w3c/csswg-drafts#7467, MicrosoftEdge/MSEdgeExplainers#1405, and w3c/csswg-drafts#9967 discuss image states and transition timing. Partner feedback requests customizable activity animation.
Proposal response. The styling appendix sketches presentation phases and author opt-in effects. Presentation phases differ from request states: an image may remain visible while a replacement loads.
Need. Choose between revealing progressive content promptly and retaining the current presentation until a complete first frame is decoded.
Evidence. MicrosoftEdge/MSEdgeExplainers#1403 discusses preview/progressive-image interaction. whatwg/html#1920 and w3c/element-timing#54 distinguish loading, decoding, and intermediate rendering.
Proposal response. The main proposal preserves native timing. The independent image-reveal: normal | complete-frame sketch would optionally wait for a complete decoded first frame, with or without a preview.
Need. Retain current content while successive images are prepared, including generated-image sequences that replace whole resources rather than progressively decode one file.
Evidence. w3c/csswg-drafts#7467 discusses visible content coexisting with a pending request. Partner feedback requests support for successive generated images and transitions between them.
Proposal response. The lifecycle discards outdated results after source changes. Whether to retain the old image or show a new preview, and how to animate successive images, remain open questions.
Need. Preserve layout, selected-image APIs, and one semantic image while accounting for visible alternative text and user preferences.
Evidence. MicrosoftEdge/MSEdgeExplainers#1408, w3c/aria#1317, and w3c/wcag#2048 address visible alt text, loading announcements, and indicator contrast.
Proposal response. Image semantics and layout remain unchanged. A preview can displace visible loading-time alt text without removing its accessible description; the accessibility guidance also covers motion and contrast.
Need. Know whether a preview loaded and appeared, coordinate UI with image replacement, and measure how previews affect the loading experience.
Evidence. whatwg/html#3631 requests preview signals. w3c/element-timing#54, w3c/largest-contentful-paint#71, and w3c/container-timing#24 distinguish intermediate content from meaningful completion.
Proposal response. It remains open how authors can detect preview success or failure and how performance metrics should account for previews. Resource Timing describes a separately fetched preview's request, not whether it was decoded or displayed.
Need. Keep ordinary images usable when previews fail or are unsupported, with predictable fallback, bounded resource use, and existing platform protections.
Evidence. whatwg/html#3631 discusses failure behavior, compatibility, and CSP.
Proposal response. Preview failures do not block the main image; main-image failure uses native fallback. Security requirements cover fetch protections and processing limits.
The explainer's earlier proposal versions preserve the old syntax and behavior, explain their limitations, and describe why the design changed.