W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > August 2011

[Bug 13599] Remove srcdoc attribute on iframe

From: <bugzilla@jessica.w3.org>
Date: Wed, 03 Aug 2011 22:35:30 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Qok2E-0000eV-0G@jessica.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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:16 UTC