我听说过shadow DOM，它似乎解决了web widget开发中的封装问题。 DOM 和 CSS 规则被封装，有利于维护。但这不是 iframe 的用途吗？ iframe 存在哪些问题使得 W3C 必须提出 Shadow DOM 或 HTML5 Web Components？
【问题讨论】：
<iframe>s 提供（太多）太多封装。
<iframe>s 获得自己的执行上下文。它们还会破坏事件流。
如今，iframe 通常用于确保单独的范围和样式。示例包括 Google 的地图和 YouTube 视频。
但是，iframe 被设计为在当前 HTML 文档中嵌入另一个完整文档。这意味着从父文档访问 iframe 中给定 DOM 元素中的值是设计上的麻烦。 DOM 元素位于完全独立的上下文中，因此您需要遍历 iframe 的 DOM 才能访问您要查找的值。将此与 Web 组件进行对比，后者提供了一种优雅的方式来公开用于访问自定义元素值的干净 API。
想象一下使用一组 5 个 iframe 创建一个页面，每个 iframe 都包含一个组件。每个组件都需要一个单独的 URL 来托管 iframe 的内容。生成的标记将充满 iframe 标签，产生语义低的标记，阅读和管理也很笨拙。相比之下，Web 组件支持为每个组件声明丰富的语义标签。这些标签在 HTML 中充当一等公民。这有助于读者（换句话说，维护开发人员）。
总之，虽然 iframe 和 shadow DOM 都提供了封装，但只有 shadow DOM 是为与 Web 组件一起使用而设计的，因此可以避免 iframe 出现的过度分离、设置开销和笨拙的标记。
【讨论】：
iframe 仅用作封装对象...
除了 SVG（稍后会详细介绍），今天的 Web 平台 仅提供一种内置机制来隔离一大块代码 另一个——它并不漂亮。是的，我说的是 iframe。为了 大多数封装需求，框架过于沉重和限制。
Shadow DOM 允许您通过创建 DOM 的另一个克隆或其一部分来提供更好、更轻松的封装。
例如，假设您构建了一个跨网站使用的小部件（就像我一样）。 您的小部件可能会受到页面上 css 的影响并且看起来很糟糕，而使用 Shadow DOM 则不会:)
这是一篇关于该主题的优秀文章：
【讨论】：