可以启动全屏 iframe 小部件吗？比。嵌入式？

Question

我需要为我的应用程序网站的用户添加一个自定义小部件，最初认为 iframe 会使其变得如此简单，原因如下：

1. 我可以使用为应用程序构建的自定义框架，它提供了大量预构建的代码和功能，我将在小部件中使用这些代码和功能，因此不必重新创建。跨浏览器事件处理程序和原型对象只是众多示例中的一小部分。
2. 我不必担心与 CSS 冲突，更具体地说 不必为我创建的每个 dom 元素使用内联 css。
3. 跨域请求不是问题，因为我已经建好了 需要使用的所有内容的功能 jsonp，所以不要让它成为嵌入式 dom 小部件的缺点。

目前的想法是编写一个快速的javascript sn-p，它本质上是一个按钮，并在全屏窗口上方加载一个透明的iframe。这将使我能够控制整个视图，并允许我像编写父应用程序的任何其他部分一样编写小部件。保持相同的 json 通信，使用相同的样式，使用框架等。单击 iframe 中不属于小部件的任何部分（可能会在屏幕中间加载，如果打开，则为全屏移动设备）将关闭小部件并使用户恢复到他们在网站内的正常导航。但是，他们可以在我的小部件启动时与它进行交互，就像它是网站的一个嵌入部分，恰好加载了一个 javascript 弹出窗口。

小部件本身与服务器的通信有些繁重。加载了一些请求，然后当用户交互时，它通常会发送一个请求，更改视图，然后等待另一个响应。

说了这么多，这是一个坏主意，还是不专业的主意？我是否应该将额外的工作直接嵌入到主机 DOM 中并重写所有方便的框架代码？我这样做没有问题，但如果 iframe 是一个更合适的选择，那么我想我宁愿那样做。我唯一的限制是我需要支持到 IE8，当然，小部件需要在桌面和移动设备上都可以查看，并且小部件不能对客户网站造成干扰。

Answer 1

其他帖子的一些好读物。虽然已关闭，但它提出了一些支持 iframe 的体面的论据。

Why developers hate iframes?

引起共鸣的几点：

1. Gmail、live.com、Facebook 上的任何其他主要网站 互联网利用 iframe 并在它们所在的情况下 使用得当……这就是它们的用途。
2. 在特别像我这样的情况下，它被认为是更好的做法 为了防止与远程网站的任何可能的兼容性问题，我 无法控制。我宁愿使用 iframe，还是销毁 个人网站？当然，我可以采取一切可能的预防措施，并且 在另一个人的网站上实际造成问题的可能性是 苗条，但使用 iframe 是不可能的。因此它们被创建的原因 首先。
3. 在我的情况下，SEO 并不重要。我只是在扩展一个 javascript应用程序到远程用户网站上，不提供 可搜索的内容。

基于上述原因，我认为采取更简单的方法实际上是更专业的选择。 iframe 通常有一点误解，我认为是因为它们过去以丑陋的方式过度使用，但是表格也有同样的误解，不管你信不信，当数据最好以表格方式显示时，它使感觉使用...等待它...表。尽管我们在诸如 display: table-cell 之类的 css 值之后执行此操作。

现在 iframe 得到我的投票。如果在这个项目的开发道路上再走一点，我会更新这个答案，我会改变主意。