This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Although srcdoc might be seen as a security improvement, it actually isn't. It adds another layer of escaping markup which can lead to errors. Especially in situations where srcdoc document will contain anorher iframe with src. If there is need for srcdoc functionality, then such functionality should be based on element not on attribute where escaping of markup is necessary.
There was a substantial amount of discussion that occurred before this was added to the spec. Using an attribute versus an element, and many variations on both ideas, were discussed and dissected. I recommend reading the HTMLWG and WHATWG mailing-list archives for those discussions, so the same arguments don't have to reoccur again. In short: @srcdoc is the method most likely to be gotten right by authors.
Despite the conversations on the lists, I still agree with Jirka that this feature increases the attack surface area by requiring the markup to be correctly escaped. No browsers implement this yet, I'd like to see this removed from the spec. I think the risk outweighs the functionality (for most of which there are other simple ways to implement the functionality).
(In reply to comment #2) > Despite the conversations on the lists, I still agree with Jirka that this > feature increases the attack surface area by requiring the markup to be > correctly escaped. No browsers implement this yet, I'd like to see this > removed from the spec. I think the risk outweighs the functionality (for most > of which there are other simple ways to implement the functionality). Can you give an example of another way to safely embed third-party content in a page without incurring a network request per piece of content, and explain how it's easier or simpler to use than @srcdoc? I believe the on-list conversations were fairly exhaustive.
How about myIframe.contentDocument.innerHTML?
(In reply to comment #4) > How about myIframe.contentDocument.innerHTML? This is strictly worse than @srcdoc in multiple ways. 1. It requires you to embed the source document in JS, and thus apply JS escaping rules, which are more complex than srcdoc's escaping rules. (srcdoc only requires you to escape your quoting character. You should also escape ampersands, but that's not important for security. Nothing else needs to be escaped.) 2. It requires scripting to work. If the user has scripting disabled, they won't get to see any of your iframe'd content. 3. You have to wait for the iframe's onload event to fire before replacing the innerHTML, or else initially point it at about:blank (which loads synchronously). This is either slower or confusing. (I'm not sure if replacing innerHTML of a quirks-mode document resets the quirks flag or not. If not, then using about:blank is out.) 4. The iframe has to be same-origin, or else you can't touch the contentDocument. This means you can't do it on sandboxed iframes, which is the primary use-case for @srcdoc anyway (so much so that I suggested @srcdoc should imply @sandbox). If you have any other suggestions, could you please list why you think they're easier or simpler than @srcdoc, like I asked? That way I wouldn't have to explain why they're actually worse; you'd figure it out yourself when trying to write it up.
mass-moved component to LC1
*** Bug 13659 has been marked as a duplicate of this bug. ***
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: Please address comment 5.