- From: Ben Vinegar <ben@benv.ca>
- Date: Mon, 3 Feb 2014 11:23:33 -0800
- To: whatwg@whatwg.org
Hi there, I wanted to offer some feedback on the seamless iframe attribute. [1] Some context: I’m a software engineer at Disqus, an embedded discussion platform that uses iframes heavily. I’m also the co-author of Third-party JavaScript, and I’ve given talks about seamless and how to emulate its behaviour in browsers that don’t support it. Ultimately, seamless doesn’t affect Disqus, because it only applies to iframes that share the same origin as the browsing context. Which is good, because we don’t want to use the seamless attribute anyways – it would let publishers manipulate the styles of our application, which besides being potentially dangerous, is not something we want them doing. But while we’re not interested in the style component of the seamless attribute, we – and probably all developers that hack on iframes – are interested in the resizing behaviour it introduces. Right now we deploy fairly complex code, both inside the iframed document, and on the parent document, to resize the iframe element when the iframed content changes size [2]. Every iframed application with dynamically-sized content does the same. To me, it’s crazy that it’s 2013 and there’s still no native way to have the browser automatically resize an iframe. And yet we have seamless. But it not only resizes: it adds all this other bundled behaviour, and strictly serves a fringe use case where somebody is distributing iframes on the same origin. My suggestion is to split seamless into its three major parts: style inheritance, iframe resizing, and browsing context. Let the iframed _document_ declare whether it opts into style inheritance and/or parent browsing context (the latter can already be achieved by <base target=”_parent”>). Let the iframe _element_ declare whether it should auto-resize (e.g. <iframe resizable>). This way each context permits the other party to have additional control over its document (e.g. the parent allows the iframe to be resized according to the iframed document’s content, the iframed document allows the parent to apply styles to it). Since the size of the iframe element could leak session information, perhaps the iframed document additionally specifies a header for permitting the behaviour (like ResourceTiming or CORS). This way, everybody wins. Embedded developers will finally have a method for having their iframes automatically resize. They’ll also be able to opt-in their documents to inherit styles from the parent document – even if they’re cross-origin. In other words, this will greatly expand the scope of possible applications beyond what seamless was capable of. Hopefully this makes sense. I've I've missed something, please let me know. Thanks, - Ben [1] http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#attr-iframe-seamless [2] http://benvinegar.github.io/seamless-talk/#/32
Received on Monday, 3 February 2014 19:23:59 UTC