[whatwg] Feedback on seamless iframe attribute

[Ryosuke Niwa]

On Feb 3, 2014, at 11:23 AM, Ben Vinegar <ben at benv.ca> wrote:
> 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.

Right.

> 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.

Yeah, this is a use case we deeply case about.

> 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.

Indeed!  Let’s solve this problem.

> 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).

An alternative is to make web components work cross-origin.  I had a straw man proposed posted on WebApps WG at W3C last year:
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0418.html

We haven’t made much progress there yet but I believe we can solve your use case if we invented some CSS primitives to clip an element and limit style inheritances.

- R. Niwa