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

Re: Trying to use <iframe srcdoc= >

From: Gavin Carothers <gavin@carothers.name>
Date: Mon, 25 Jan 2010 15:28:39 -0800
Message-ID: <273883011001251528t4a66a8b0uc0d5426f78b64c8b@mail.gmail.com>
To: HTMLwg <public-html@w3.org>
On Mon, Jan 25, 2010 at 3:12 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Mon, Jan 25, 2010 at 5:07 PM, Gavin Carothers <gavin@carothers.name> wrote:
>> 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.
>
> You can still use @src to point to the comment directly.  A browser
> that supports @srcdoc will ignore the @src.
Now with @src:

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

Okay it is better, at least there content is there now.

>
> The important thing, though, is to feature-test for @sandbox support,
> as that's the relevant part.  In general, using <iframe>s for this
> sort of thing won't be feasible for a few years, until all relevant
> browsers support @sandbox.

Errr... so I'm still missing the advantage to be me an
author/publisher. I still have to do all the work I'm doing today, and
it radically increases the number of requests to my server and more
then doubles the number of bytes I have to serve (until browsers
support srcdoc, then it's negligible). In the mean time I'll destroy
the searchability of the page, and slow down my users experience. All
in the name of
possible future security? We're going to need to do better selling
this feature if we want to keep it.

--Gavin
Received on Monday, 25 January 2010 23:29:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:00 GMT