The direct answer
For a deliberately separate HTML preview, require an explicit capability plan rather than treating an iframe as a safe display box. A present, empty sandbox token set can be part of that plan, but content admission, resource controls, browser support and current-view association still need independent verification; the preview grants no action authority.
Keep the preview separate from ordinary answers
Suppose a console offers a visual preview of one generated release note. Its ordinary answer renderer already excludes embedded frames. Keep that rule: a new preview surface needs its own review, owner and failure behavior. Do not silently extend the answer renderer because a note looks harmless in a screenshot.
This proposed profile permits only one bounded, already-authorized note. It has no child messaging, transferred secrets or business-action controls. The host owns the surrounding label and identifies the content as an untrusted generated preview. A human may inspect its layout; neither a convincing button nor a familiar logo inside the note becomes a trusted console control.
The following worksheet is PROPOSED_UNRUN. No iframe, DOM assignment, markup fixture, script, navigation or browser experiment was performed. It defines questions for a future implementation review, not a verified browser configuration.
Review tokens as permissions, not formatting preferences
MDN documents that an empty sandbox attribute applies its restrictions; tokens lift particular restrictions. Omitting the attribute does not select that empty-token policy. allow-scripts permits child script execution. Without allow-same-origin, the child has a special origin that fails same-origin checks. For content same-origin with its parent, combining both tokens can let the child remove sandboxing. Treat the combination as a capability change. MDN iframe reference.
Freeze this application plan with the attribute present and no tokens. Convenience requests for scripting, forms, popups, top navigation or downloads require a different design review; they are outside this plan. Review the complete embedding configuration, not just a screenshot of one attribute. This sheet does not establish universal browser isolation, eliminate visually misleading content or prove that all possible navigation paths are confined.
srcdoc remains a content-admission boundary
The srcdoc property parses HTML and replaces the frame document; it is an injection sink. MDN warns that an unsandboxed document, or one with same-origin permission, can share parent-origin access. A familiar property name therefore supplies no content-trust decision. MDN srcdoc reference.
Require an independently supported, reviewed HTML admission and sanitization path before assigning anything. Its policy must cover the entire admitted document and the actual sink. This guide does not implement that path, Trusted Types or a CSP policy. Unknown coverage blocks the preview; adding an iframe is not a substitute for the missing review.
Also review every URL-bearing feature and resource destination. Relative URLs in a srcdoc document use the embedding page as their base, and srcdoc overrides src. Unsupported attribute implementations can fall back to src. MDN source and base-URL behavior. The selected plan must establish the actual supported property path and exclude an unintended fallback. Script restrictions alone establish neither a no-network policy nor confidentiality.
Bind one capability sheet to one admitted note
Use invented labels N-A for the note, R-A for its admitted revision and V-A for the current console view. These labels are not credentials. The sheet records the authorized viewer and scope, content and resource-policy decisions, reviewed browser coverage, host-controlled embedding configuration, and the exact note revision associated with the view.
A useful ordinary positive is a small release note containing an admitted heading and two plain paragraphs, with no links or external resources. If all earlier checks and the supported lifecycle are independently established, the plan may become eligible for that separate preview. None of those application prerequisites is implemented or demonstrated here. Unknown evidence stays a hold rather than a successful preview.
Eight inert capability-review cards
These eight cases are proposed review inputs, not executed tests or browser outcomes. Every eligible decision remains conditional on the earlier prerequisites.
| Card | Proposed observation | Decision and next step |
|---|---|---|
| 1. Ordinary note | N-A/R-A/V-A match; all prior gates and the fixed empty-token plan are established. | Eligible only for the separate preview; record the evidence and scope. |
| 2. Omitted attribute | A refactor drops sandbox instead of preserving its empty value. | Reject the changed contract; require the original explicit plan. |
| 3. Interactive convenience | A proposed revision adds script permission. | Outside this profile; do not approve it as a cosmetic change. |
| 4. Origin relaxation | A revision requests same-origin permission, with or without scripts. | Reject under this plan; require a separate authority review. |
| 5. Unadmitted content | Generated content lacks complete prior content/sink review. | Hold before display, even when the token sheet matches. |
| 6. Resource uncertainty | A note gains relative links or unreviewed resource destinations. | Hold for independent resource admission; claim no privacy guarantee. |
| 7. Widget compatibility | A proposal accepts child traffic through a null-origin or wildcard workaround. | Reject; this preview has no message-based authority channel. |
| 8. View drift | The note revision, view or embedding plan changes after review. | Invalidate eligibility; require a supported fresh association. |
Report eligibility separately from successful display
Keep the existing cooperating-widget protocol separate. Its explicit-origin and current-window requirements are not relaxed to accommodate this preview. Keep actual actions in trusted host controls with current authorization and any required approval; content shown inside the frame cannot attest to either.
Record an honest outcome: held for missing evidence, rejected for a changed capability plan, or conditionally eligible for a specific admitted note. Successful display, lifecycle correctness, rendering quality and browser compatibility would require separate verification. Do not infer them from configuration review or an apparently complete note.
Boundary remains prelaunch. Planned request-path checks do not supply an iframe renderer, sanitizer or browser capability controller. This worksheet is educational and does not describe a shipped Boundary preview feature.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.