W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2014

Re: [whatwg] Feedback on seamless iframe attribute

From: Ryosuke Niwa <rniwa@apple.com>
Date: Thu, 06 Feb 2014 00:38:27 -0800
Message-id: <F293E289-5958-437E-A0AD-D2DF90D2B451@apple.com>
To: Ben Vinegar <ben@benv.ca>
Cc: WHATWG List <whatwg@whatwg.org>
On Feb 3, 2014, at 11:23 AM, Ben Vinegar <ben@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.


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

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
Received on Thursday, 6 February 2014 08:38:55 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:15 UTC