- From: <bugzilla@jessica.w3.org>
- Date: Wed, 03 Aug 2011 22:35:30 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13599 --- Comment #5 from Tab Atkins Jr. <jackalmage@gmail.com> 2011-08-03 22:35:29 UTC --- (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. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 3 August 2011 22:35:30 UTC