This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://html5.org/tools/web-apps-tracker?from=4580&to=4581 text/sandboxed-html and <iframe sandbox> don't have the same backcompat story. Is this intentional? It seems to me that we either want a parameter for text/html or a new element. Also: do we care about sandboxed XHTML or SVG?
The back-compat story for text/sandboxed-html is that the media type triggers a download in legacy UAs, which is safe. @sandbox purposefully defaults to open in old UAs. That's so that folks can deploy @sandbox for defense in depth on existing web properties. By combining the two, you can get a fail-safe behavior in old UAs for @sandbox.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: What Adam said. I have no opinion on whether XML should be sandboxed; that seems out of scope for this group. (If the XML or SVG groups want HTML5 to define a sandboxed type for them, I'm happy to oblige, of course. I just don't want to step on toes when it's not necessary for getting interop on existing features.)