GithubHelp home page GithubHelp logo

autoresize iframes spec about iframely HOT 14 OPEN

itteco avatar itteco commented on July 23, 2024
autoresize iframes spec

from iframely.

Comments (14)

iparamonau avatar iparamonau commented on July 23, 2024

We have something similar specified in Iframely protocol - https://github.com/itteco/oembed2/blob/master/4%20-%20Embed%20MIME%20types.md

Have you seen it?

from iframely.

nleush avatar nleush commented on July 23, 2024

In addition to Ivan:

Example usage here: https://github.com/itteco/iframely/blob/master/plugins/domains/facebook.com/facebook.post.ejs

But you are right, it needs to be more unified for common cases.

Also we are looking at google plus posts embedding style:

https://developers.google.com/+/web/embedded-post/

This method have flexibility and performance benefits on multiple embeds, but it also not so safe as iframe.

I will think about you ideas.

from iframely.

nleush avatar nleush commented on July 23, 2024

Maybe only width, height, overflow and background should be supported?

height - in most cases. Width usually are floating. If widget know its width and height it can specify it by media

Usually widgets have static width, and height depends on amount of text. So it could be calculated only after render. And this is not so easy, because content can load dynamically and height will change permanently. We had problem with this in storify plugin.

If widget has floating width - it will calculate height depending on configuration of iframe set by parent and media constraints. And the rest will be all the same as in previous case.

overflow and background - works inside iframe content as I know. How can it act in iframe from parent window?

Maybe you mean ALLOWTRANSPARENCY?

from iframely.

panzi avatar panzi commented on July 23, 2024

Oh, indeed. I haven't seen this. But it has a few problems:

It uses objects, not strings. caniuse.org: "Internet Explorer 8 and 9, and Firefox versions 6.0 and below only support strings as postMessage's message." Especially IE 8 and 9 would be targets that should be supported. Look at the combined market share of IE 8 and 9: http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0

Also the windowId is a bit more complicated than necessary. It means that the iframe has to do more complex communication with it's parent (the order of "register" and "iframe loaded" can be arbitrary, sending "resize" has to happen after both). In my example no windowId is needed because it always searches through all iframes and compares iframe.contentWindow === event.source.

And then the message format is a bit generic. I would mark it somehow more unambiguously. In my example I prefixed the message data with iframely:.

I think the simpler the API, the more likely it will be implemented. Ok, my example needs a bit of a script on the side of the embedder, but it's not that big and can be embedded once without the need of adding logic that assigns windowIds to iframes.

from iframely.

nleush avatar nleush commented on July 23, 2024

Registering needed to control flow from parent window. Iframe can send signal before events in parent window will be set up. I don't know how critical could it be, but if all this managed by common lib - complexity is not so important.

So its more about control - not to find who sent event.

from iframely.

panzi avatar panzi commented on July 23, 2024
`overflow` and `background` - works inside iframe content as I know. How can it act in iframe from parent window? Maybe you mean ALLOWTRANSPARENCY?

Ah, yes. I also mean allowtransparancy. But actually in my experience you have to set all these things (allowtransparency="true", background:transparent, scrolling="no", overflow:hidden) to be on the safe side. But yes, allowtransparency is missing in my example. Also it seems as if it's no longer supported with IE9. Updated: http://jsfiddle.net/nxUVp/11/

Also now I have second thoughts about some aspects of my example: You can do a lot of shenanigans with CSS. It should not only filter the property names, it should also filter the values (only allow certain value patterns), because e.g. in IE you can embed JavaScript expressions in CSS! So I guess: only allows width and/or height which have to be parsed by parseInt(value, 10), all the rest has to be done by by the embed user (specifying allowstransparency and frameborder etc.).

from iframely.

panzi avatar panzi commented on July 23, 2024

@nleush If the onmessage handler is registered in <head>, then no iframe message should arrive "too early". If the embed user set's up thing asynchronously, they can register a simple onmessage handler that remembers the messages. I think it should be simple for the simple case. E.g. a user want's to have auto resizing iframes, so they just put one simple <script src="..."></script> into their <head> and they are done.

Because I think simplicity is important, here is a simplified version of my example:
http://jsfiddle.net/Cjs7x/2/
http://jsfiddle.net/kBh7c/2/

from iframely.

iparamonau avatar iparamonau commented on July 23, 2024

I like your ideas, Mathias. Having the need for iframe to register itself first isn't the nicest thing. However, we should keep in mind that the same mechanism we'd choose for auto-resizing will also be used for playback sync.
Like sending the sequence of events "user started my player- parent stop everyone else". "Ok everyone: stop". "1st - stopped, 2nd - stop".

Let us think a little more about your suggestions. The goal is to have simple, but not too ambiguous spec

from iframely.

panzi avatar panzi commented on July 23, 2024

I agree. Anyway, I think the most important thing is to use strings instead of objects (IE8 and IE9 support) that are prefixed with something unique like iframely: and general simplicity. If one want's to send more complex data, one could use JSON.stringify/parse. The JSON object is supported in all browsers that support postMessage (well, for Opera JSON support came a tiny bit later, but for IE it's the same).

from iframely.

nleush avatar nleush commented on July 23, 2024

Ok, lets see what separate problems we have.

  1. parameters available to sent to parent. We can allow object pattern (useing JSON.stringify) but recommend using limited list of attrs.
  2. iframes registering / listening mechanism to sync parent and iframe windows. All must be ready to connect and use two side communication protocol.
  3. Browsers compatibility. Stringss/objects/hashes.

Thats all.

About 1.

Now we support height, its not a problem to add width. Other css attrs looks like more complex logic for me. As I understand you and css:

  1. transparency=true will make: allowtransparency="true", background:transparent
  2. overflow=hidden will make scrolling="no", overflow:hidden

And thats only two cases.

About 2.

As I told I want to have control over all iframes as a parent window. I had cases with async scripts loading in parent window. That's mean it would be +1 problem to bind head event and make queue with iframes messages.

In my current solution you need one script and one function call to start managing iframes in page. No care when it called.

If we listening to head, we need to make parent window use head script. Thats limitation to user. In case of complex async apps it could be a problem.

From the other side: If we use iframely.js to render iframes, then it will be already initialized to listen iframes it created. Buy in case of server render we should force some script loading in head.

So in both cases we have some explicit restrictions:

  1. place script in head or launch script before iframe inserted.
  2. call script after iframe inserted.

I don't have clear vision what is much better, but as I told - i think second case is more manageable.

About 3.

I use this http://www.onlineaspect.com/2010/01/15/backwards-compatible-postmessage/ code in all iframely libs. Its a bit truncated in iframely version, but its not a problem to return full version. Lets assume this code handles browser support and object->string->object conversion.

from iframely.

nleush avatar nleush commented on July 23, 2024

One more problem we have with that - is detecting real window size inside iframe. Its not about spec, but more like: how and when detect content size.

In common case iframely acts like following:

  1. calculates default iframe some positive size which will be resized later.
  2. render iframe with wrong size, it can show scrollbars, white rectangle or content partially.
  3. when iframe script know size - iframe will be resized by parent.

The biggest problem here is following:

Iframe should have some (incorrect) size initially. And that size will be visible to user sometime (wait for content loaded). Its very ugly. Positive height allow iframe content be rendered and have real size with scrollbars. I tried to make initial height=0 but that cause problems to iframe window to detect size. Maybe more hacks needed.

Also I had problems with size change after scrollbar added or disappeared.

You can play with that using plugins which use iframely-utils.js.

from iframely.

panzi avatar panzi commented on July 23, 2024

What if you make the iframe filter: alpha(opacity=0); opacity: 0; instead of height:0px;? Yes, it will occupy a wrong size initially, but it would be less of a problem than rendering scrollbars/a white rectangle/partial content. Maybe visibility: hidden; would also work, but one have to test it (maybe browsers optimize that case by not calculating anything, that's what happens with display: none; anyways).

from iframely.

panzi avatar panzi commented on July 23, 2024

You could wrap the iframe in a div that has overflow: hidden; width:0px; height:0px;. Requires more HTML, though.

from iframely.

iparamonau avatar iparamonau commented on July 23, 2024

@panzi I've moved this into itteco/oembed2 repo. Please, join there. We are also discussing the initial handshake in itteco/oembed2#3

from iframely.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.