Re: [whatwg] Feedback on seamless iframe attribute
> The main use case is same-origin-served blog comments, which isn't that fringe, to be fair. Are you aware of any other products/companies using same-origin-served blog comments, that aren't Google Plus/Blogger? Genuinely curious. - Ben On Wed, Apr 30, 2014 at 1:22 PM, Ian Hickson wrote: > > On Mon, 3 Feb 2014, Ben Vinegar wrote: > > > > 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. Every iframed application with dynamically-sized content does the > > same. > > Thanks for descrbing this use case. > > It has come up before, as it happens. Combined with the desire for other > aspects of seamless="" to apply to cross-origin iframes, the current > proposal is to have headers that enable these features on the embedee > site, with CSP being used to decide which origins are allowed to use the > feature at all. You can see more about this at these links: > > > http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0207.html > > http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0006.html >https://www.w3.org/Bugs/Public/show_bug.cgi?id=23513 > > The current blocker is getting implementor interest; right now, most > implementors haven't finished (or in some cases even started) supporting > seamless="" even for same-origin iframes, so we don't want to start adding > more features yet lest we get too far ahead of the browsers. > > > > 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. > > The main use case is same-origin-served blog comments, which isn't that > fringe, to be fair. > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Feedback on seamless iframe attribute
On Mon, 3 Feb 2014, Ben Vinegar wrote: > > 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. Every iframed application with dynamically-sized content does the > same. Thanks for descrbing this use case. It has come up before, as it happens. Combined with the desire for other aspects of seamless="" to apply to cross-origin iframes, the current proposal is to have headers that enable these features on the embedee site, with CSP being used to decide which origins are allowed to use the feature at all. You can see more about this at these links: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0207.html http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0006.html https://www.w3.org/Bugs/Public/show_bug.cgi?id=23513 The current blocker is getting implementor interest; right now, most implementors haven't finished (or in some cases even started) supporting seamless="" even for same-origin iframes, so we don't want to start adding more features yet lest we get too far ahead of the browsers. > 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. The main use case is same-origin-served blog comments, which isn't that fringe, to be fair. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Feedback on seamless iframe attribute
On Feb 3, 2014, at 11:23 AM, Ben Vinegar 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 target=”_parent”>). Let the iframe _element_ declare whether it should > auto-resize (e.g. ). 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
