[whatwg] Feedback on seamless iframe attribute

[Ben Vinegar]

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