- From: Gavin Carothers <gavin@carothers.name>
- Date: Mon, 25 Jan 2010 15:07:33 -0800
- 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