W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Trying to use <iframe srcdoc= >

From: Gavin Carothers <gavin@carothers.name>
Date: Mon, 25 Jan 2010 15:07:33 -0800
Message-ID: <273883011001251507r30a0be21i37dfe89c5ec9e0ca@mail.gmail.com>
To: HTMLwg <public-html@w3.org>
In order to form a better opinion on how srcdoc might work, I figured
I'd try it out on a use case that doesn't exactly match the blog
comments in the spec but is reasonably close.

http://oreilly.com/catalog/errataunconfirmed.csp?isbn=9780596101992

This page allows our customers to enter errata (errors) found in our
books. Unsurprisingly with a book about Javascript some of the errors
involve customers entering Javascript code they expect to be displayed
on the website. An early version of our software had, as one might
expect,a script injection bug in it. We are currently looking at
updating said system and looked like a good use case for srcdoc.

I'm afraid I'm not going to be going very far with this:

http://gavin.carothers.name/iframe-srcdoc/iframe-srcdoc.html

Did a quick test by hand for just one entry. The problem should be
very apparent. No browser today supports srcdoc, and when it fails no
content is shown on the page. It would be impossible to adopt using
srcdoc for any content to be shown on a page. While it would be
possible to do server side UA detection there is little reason to as
we would have to continue to maintain a server side sandboxing method
for all current browsers. Given that we would still need to do all the
sandboxing/escaping/validation work there seems little benefit to
adding a UA detection mechanism to support this feature.

Am I missing something? This doesn't seem like a place where adding
iframes with srcdocs via javascript if supported would make any sense
as the whole point of srcdoc is to avoid the additional HTTP requests.

--Gavin
Received on Monday, 25 January 2010 23:08:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:13 UTC