Feature request: responsive iframe

[thomaswilburn]

I work at the Seattle Times and this effort is really interesting to me. However, one of the techniques we use regularly is to embed interactive content in our CMS via a responsive iframe. This is pretty common - we use our custom element, and a lot of other organizations use NPR's Pym library. However, the iframes available in AMP can't resize themselves, and it looks like responsive frames would be forbidden by the width/height restrictions of the format. Would there be an opportunity to add responsive frames to AMP, maybe with a click-to-play UI to prevent startup jank?

[cramforce]

Responsive iframes are allowed, but not "fluid" ones that resize themselves.

We will, indeed, do a click to play thing. Is on our pretty immediate agenda to find a good design and implement it.

[tmaslen]

We also use responsive iframes for interactives at BBC News too. Would be interesting to see an AMP native implementation of a responsive iframe. Happy to help out if needed.

[dvoytenko]

Thanks, Tom! Do you think you could share an article where you use a "responsive iframe"?

[thomaswilburn]

Here's one at the ST: http://www.seattletimes.com/business/real-estate/buffetts-mobile-home-business-has-most-to-gain-from-deregulation-plan/ The interactive graph partway down the page is embedded via a <responsive-frame> element, which controls its child iframe in response to messages from the embedded page.

[tmaslen]

Hi,

Not sure if you mean me or Thomas Wilburn :-) Here's an example from me too:

http://www.bbc.co.uk/news/technology-34066941

Right now this content doesn't appear in our native apps. We're in the process of updating our apps to use the source of the iframe as the source for a webview. The iframe technique is great for our interactive devs as the bespoke content is statically published to the news website which is a PHP application. Sandboxing our content in an iFrame allows the host page to update without ever affecting our content. I'd imagine the same reasoning was behind the ST usage of an iframe?

Cheers,
/t

[cramforce]

implements at least our notion of responsiveness.

[thomaswilburn]

Mostly we do it because our CMS is WordPress, and it's just much easier to manage assets and scripts on S3 than try to hack it into a post. In certain places on the page (mostly the header or sidebar), we can protect the embed from content updates, but in cases where we can't (say, when a story is repeatedly pushed out from the print CMS), it's much easier to re-insert a single tag than it is to shove an entire interactive back in.

[thomaswilburn]

Malte, I don't think that entirely covers our use case. We need the height of the element to be able to change, in addition to the width. As I said, it's fine if this is behind click-to-play or restricted to user action, but it's the one thing AMP can't really do for us right now.

[tmaslen]

With a "click to play" action you may as well load the iframe contents directly into the browser and leave behind the host page?

I'm with thomas, our interactive content also requires to go at least to 100% of the parent element (on devices large enough only for a single column this would be the full width of the screen) and also have variable height.

There are other NFRs based around a responsive iframe too involving:

• bundling analytics of user behaviour inside the iframe with analytics happening outside the iframe.
• any sharing to social media would share the host page rather than the iframed content.
• Scroll to commands to the host page that come from the iframe (particularly useful when the iframe is taller than the viewport).

A native AMP element that dealt with all of the above would be useful to us.

/t

[thomaswilburn]

I was thinking "click to play" might have a splash image to start, then load the iframe from there. Our embedded graphics don't currently have to load all the other crap (headers, navigation, social media, comments, extra styles) that a full standalone page has to have, so I don't really want to send people there directly.

We have a mechanism for communicating to the outside frame around your other uses, but we haven't used it much, and obviously with AMP we wouldn't really have any scripts on the host to communicate with.

[tmaslen]

Splash image to start is how we are implementing our interactive content into our native apps.

Our own custom responsive iframe code passes analytics to the host page as well as telling our customised share plugins ("I scored 7 out of 10 on the weekly quiz") inside the iframe what URL to share.

[cramforce]

It is super great to hear that click0to-plat would work for people. We will definitely make a component that can load an iframe (or render content via Ajax) where the new content can choose its own size!!!

[tmaslen]

Hi cramforce, so to clarify: when you say "new content can choose its own size" would this size definition be a one off at load time, or would the element be resizable at anytime?

None of the responsive iframes my team creates makes excessive size changes to the iframe. My current implementation is constantly checking to see if a new size request is made, but I think this can be replaced with mutation events. If this was a concern you could rate limit the requests with animationRequest, etc.

[cramforce]

@tmaslen You really need to resize more than once?

Iframe resizes are a very expensive operation. Should really only be done rarely.

[DeanMarkTaylor]

How would something like this deal with the following?:

• users rotating their devices and changing the orientation.
• users resizing the browser window.

[cramforce]

All elements get to resize themselves on user action like resize and
orientation change.

On Fri, Oct 9, 2015 at 9:05 AM Dean Taylor notifications@github.com wrote:

How would something like this deal with the following?:

• users rotating their devices and changing the orientation.
• users resizing the browser window.

—
Reply to this email directly or view it on GitHub
#495 (comment).

[thomaswilburn]

Being able to resize repeatedly, in response to user input, is essential. If you look at the example I posted, the text shown in the interactive changes as the user flips through the different visualization modes. We need to be able to grow or shrink to fit that content.

[cramforce]

Right, agree that we need to make it work. Would like to avoid something
like iframe size based animations but I think in general it is OK to resize
after that has happened once.

On Fri, Oct 9, 2015 at 9:25 AM Thomas Wilburn notifications@github.com
wrote:

Being able to resize repeatedly, in response to user input, is essential.
If you look at the example I posted, the text shown in the interactive
changes as the user flips through the different visualization modes. We
need to be able to grow or shrink to fit that content.

—
Reply to this email directly or view it on GitHub
#495 (comment).

[thomaswilburn]

Sure, I don't think it's essential that it be animated. I'd be more than happy to batch or debounce resize requests.

[dvoytenko]

@thomaswilburn and @tmaslen thanks a lot for your examples.

Let's call "responsive" the stuff that has predictable size (e.g. with aspect ratio) and simply uses space well. And let's call "dynamic-height" or "autogrowing" the stuff that has to wait for content to arrive to actually know what space it needs.

With that I wanted to confirm: your examples are very much predictable size. Are you saying that you have to use a "dynamic-height" approach because CMS would not otherwise allow you to express the size?

I do think we can do a lot with action-based approach. We could have a "see more" to expand the section to dynamic height. Or we could develop some really nice lightbox concept when users can interact with the embed on the whole screen. I think lightbox concept could be very promising since it could maximize the value of the embed and provide a really interactive dimension to the story.

[thomaswilburn]

Well, they're not really a predictable height. If a user expands out a
portion of the interactive, the height of the embedded element will
change - perhaps we show an additional factbox when they click on a bar,
or we allow them to expand one row of the table to get more information.

For example, take this searchable database of vaccine exemption rates at
Washington State schools:
http://blogs.seattletimes.com/fyi-guy/2015/02/04/explore-this-vaccine-exemption-rates-for-every-washington-school/

When the user searches for a school by name, ZIP, or whatever, the table
re-filters to fit that query. Between the filter, the vagaries of font
sizes, and responsive variation, we don't know how tall the table is,
ever. It's fine if its container frame only updates once every N
milliseconds. But otherwise, we have to put that table (and tables like
it) on its own page entirely, and that extra click means a dramatic
drop-off in the number of people who will see it.

We can probably define a click-to-play thumbnail, and that can have a
predictable size. But the content itself does not, and will not. And
without a way to embed these variable-height interactive graphics in our
stories, AMP is probably a non-starter for us (and for organizations
like NPR, which relies on Pym for variable-height iframes even more than
we do).

On 2015-10-09 11:27, Dima Voytenko wrote:

@thomaswilburn and @tmaslen thanks a lot for your examples.

Let's call "responsive" the stuff that has predictable size (e.g. with
aspect ratio) and simply uses space well. And let's call
"dynamic-height" or "autogrowing" the stuff that has to wait for
content to arrive to actually know what space it needs.

With that I wanted to confirm: your examples are very much predictable
size. Are you saying that you have to use a "dynamic-height" approach
because CMS would not otherwise allow you to express the size?

I do think we can do a lot with action-based approach. We could have a
"see more" to expand the section to dynamic height. Or we could
develop some really nice lightbox concept when users can interact with
the embed on the whole screen. I think lightbox concept could be very
promising since it could maximize the value of the embed and provide a
really interactive dimension to the story.

---

Reply to this email directly or view it on GitHub:
#495 (comment)

[cramforce]

Just created #571 to track implementing <amp-click-to-play>

[dvoytenko]

Definitely, when user takes an action we can do a lot more and remove many restrictions. Simply put because the user has asked for it.

[tmaslen]

This is awesome. Getting content parity between our responsive and AMP sites is an important milestone for us. Not doing this sooner harmed our responsive redesign which we started in 2012. As I said in my comments at the beginning we're only just getting interactive content into our apps in 2015, so having this feature available in AMP is a big win for us.

Thanks AMP team :-)

[EsaMakinen]

There seems to be multiple ways how Iframe resizing is implemented. We at Helsingin Sanomat use this library: https://github.com/davidjbradshaw/iframe-resizer. For our native apps, we use body.offsetheight to get sizes. So Amp needs to decide which conventions to use. Also, multiple resizes are a must.

[thomaswilburn]

I imagine if amp-click-to-play becomes a thing, we'll all have to teach our respective guest pages to talk to it. That probably makes more sense than trying to support all the different approaches people have (although our library just sends JSON, and it looks like @EsaMakinen's does too).

[tmaslen]

Yup, standardising an API for the content inside the iFrame to chat to the iframe element would be good.

[EsaMakinen]

Yeah, as long as one solution works for all use cases (web and native), it's fine. Then the same technique can be also used for non-Amp pages.

[cramforce]

Interface will be something like

parent.postMessage({
  sentinel: 'amp-iframe',
  type: 'resize',
  width: '400' /* px */,
  height: '500',  /* px */
}, '*');

If there was an actual standard for these messages it would be easy to support. It is important that the message contains something like sentinel: 'amp-iframe', that makes it easy to filter messages since all message events between windows use the same event bus.

How dimensions are measured is up to the application.

CC #571

[tmaslen]

We often have many iframed content on a single page. We namespace postMessages to ensure they don't collide.

How do you feel about there being more than one responsive iframe in the page?

[zohf]

Hi y'all. Just wanted to chime in with some thoughts.

Here is an example of a sortable table that we've iframed into a story: http://www.theverge.com/tldr/2014/11/13/7213879/how-much-would-it-cost-to-buy-everything-advertised-in-an-nfl-game. You can see that by interacting with some of the elements, the entire interactive resizes, and this is achieved with PYM. I'm unsure if a 'click-to-play' button would make a ton of sense with something like a sortable table, but it's better than it being cut off.

Secondly, on the topic of variable height, responsive interactive elements being iframed into articles, we actually put this power into the hands of our editorial staff (via Autotune: www.github.com/voxmedia/autotune). By doing so, the height of graphics created is entirely unpredictable and completely variable, so it's impossible for us to specify any heights, it has to be measured.

Thanks so much for all of the consideration around a solution for this problem. Embeddable graphics and interactives as iframes are becoming much more common in the stories we tell at Vox Media, so support for them would be oustanding.

[cramforce]

@zohf I think #728 should cover your use case.

[zohf]

Thanks @cramforce 👍

[cramforce]

Will close this as we now have implementation bugs for all aspects.

[dvoytenko]

As per #728 the next release will see the first version of resizable iframes. There are a few more separate requests in the queue to improve it, but this version should be fully functional. The docs have been updated here:
https://github.com/ampproject/amphtml/blob/cbaeb24969a4c4dd650e53d5e82b78c27f754030/extensions/amp-iframe/amp-iframe.md