《WebKit 技术内幕》之五（4）： HTML解释器和DOM 模型

4 影子（Shadow）DOM
        影子 DOM 是一个新东西，主要解决了一个文档中可能需要大量交互的多个 DOM 树建立和维护各自的功能边界的问题。

4.1 什么是影子 DOM
        当开发这样一个用户界面的控件——这个控件可能由一些 HTML 的标签元素组成，这些元素可以组成一颗 DOM 树的子树。这样一个 HTML 控件可以被到处使用，但是问题随之而来，那就是每个使用控件的地方都会知道这个子树的结构。 当网页的开发者需要访问网页 DOM 树的时候，这些控件内部的 DOM 子树都会暴露出来，这些暴露的节点不仅可能给 DOM 树的遍历带来很多麻烦，而且也可能给 CSS 的样式选择带来问题，因为选择器无意中可能会改变这些内部节点的样式，从而导致很奇怪的控件界面。

        如何将内部的节点信息封装起来，就像 C++ 语言的类一样，同时又能够将这些节点渲染出来呢 ？ W3C 工作组提出的影子 DOM 概念。影子 DOM 的规范草案能够使得一些 DOM 节点在特定范围内可见，而在网页的 DOM 树中却不可见，但是网页渲染的结果中包含了这些节点，这就使得封装变得容易很多。

        下图描述了 HTML 文档对应的 DOM 树和 “div” 元素包含的一个影子 DOM 子树。当使用 JavaScript 代码访问 HTML 文档的 DOM 树的时候，通常的接口是不能直接访问到影子 DOM 子树中的节点的，JavaScript 代码只能通过特殊的接口方式。

        HTML5 支持了很多新的特性，例如对视频、音频的支持，读者会发现这些元素其实是由很复杂的控制界面组成，这些界面也是使用 HTML 元素编写，但是在 DOM 树中，你无法找到相应的节点，这其实也是使用了影子 DOM 的思想。

        因为影子 DOM 的子树在整个网页的 DOM 树中不可见，那么事件是如何处理的呢 ？事件中需要包含事件目标，这个目标当然不能是不可见的 DOM 节点，所以事件目标其实就是包含影子 DOM 子树的节点对象。事件捕获的逻辑没有发生变化，在影子 DOM 子树内也会继续传递。当影子 DOM 子树中的事件向上冒泡的时候， WebKit 会同时向整个文档的 DOM 上传递该事件，以避免一些很奇怪的行为。

4.2 WebKit 的支持
        WebKit 已经支持影子 DOM 的规范草案，虽然还存在一些问题。支持影子 DOM 的相关类在目录 “Source/core/dom/shadow” 下，里面的主要类是 ShadowRoot ，表示的是影子 DOM 的根节点。ShadowRoot 类继承自 DocumentFragment 类，所以它同样有 Node 节点的属性和方法，因而在影子 DOM 树的内部，遍历树没有什么特别不同的地方。

        当遍历 HTML 文档对应 DOM 树的时候，WebKit 需要做特别的判断，所以读者会发现在 WebKit 的 Node 类实现中存在大量的条件语句，用来检查当前节点是否是 ShadowRoot 对象，如果是该类的对象，把它作为不同 DOM 树之间的边界。有时候 WebKit 还需要对 ShadowRoot 对象作出特别处理，比如某些情况会略过它的子树，同样的，在事件处理的支持类 EventPathWalker 和 EventRetargeter 中，也需要做一些特别的处理逻辑，原理就是上面所述，细节不再介绍。

4.3 实践：使用影子 DOM
        示例代码 5-2 给出了一个简单的使用 webkitCreateShadowRoot 接口来创建影子 DOM 子树的例子。网页只包含了一个 “div” 元素，JavaScript 代码使用该元素创建了一个影子 DOM 子树的根节点，然后该根节点下加入了两个子女，第一个是图片元素，第二个是 “div” 元素，该元素内部包含了一些文本。

          打开 Chrome 浏览器的开发者工具，然后打开控制台，在其中输入 “document.firstChild.firstChild.nextElementSibling.firstElementChild.firstElementChild” 后会发现结果是空的，根据对应关系 “#document-> html -> head -> body -> div -> null”,虽然网页中没有 ‘head’ 元素，但是 DOM 树仍然会创建该节点。同时读者会发现 “div” 元素没有子女，影子 DOM 子树真的被隐藏起来了，成为真正的影子。