首页 > 代码库 > 跟随标准与Webkit源码探究DOM -- 获取元素之getElementsByName

跟随标准与Webkit源码探究DOM -- 获取元素之getElementsByName

2024-08-03 19:25:53   219人阅读

按照name属性获取多元素 -- getElementsByName

标准

  • DOM 1 定义在HTMLDocument Interface 中，原型NodeList getElementsByName(in DOMString elementName)，该方法不会抛出任何异常。
  • DOM 2依然定义在HTMLDocument，原型不变，但是新增说明在 HTML4.0 里搜索范围为所有元素，而 XHTML 1.0 里搜索范围缩小到表单元素
  • DOM 3没有 DOM HTML 的标准，沿袭 DOM 2（DOM 3 有 Document 所属的 DOM core标准，但HTMLDocument属于 DOM HTML 而不属于 DOM core）
  • WHATWG 在 DOM HTML 标准里 override 了 Document 而不是另开一个 `HTMLDocument，原型不变
  • W3C HTML5和 WHATWG 基本一致

注意点

  • name 和 id 不同，可以重复，因此这个方法名字里有“s”，并且返回的是NodeList
  • 这个方法返回的是一个 “live” 的NodeList，当页面元素改变后，再次调用获得的NodeList会跟着更新。
  • 当没有符合要求的元素时，返回的不是 null，是一个空的NodeList
  • 元素的 name有两种，一种已经在该元素的IDL里，另一种只是名字为name的属性（Attr）
  • 一些浏览器还提供document.name这种直接获取name为name的元素的方式，但这个特性并未出现在标准中，一些新的浏览器也开始不支持这种获取方式了，所以最好不要用

兼容性

IE9- 只算入 HTML4 允许带 name 的元素（换句话说，只算入IDL里有name的元素）。但是它们又有一个 bug ：算入任何 id 与所搜索的name相同的元素。

检查

<!DOCTYPE html><html lang="en"><head>    <meta charset="UTF-8">    <title>Document</title></head><body>    <div id="foo"></div>    <a name="bar"></a>    <div name="baz"></div></body></html>

IE 9- 下：

  • document.getElementsByName(‘baz‘).length返回 0（因为 HTML 4 中 div 不能带name）
  • document.getElementsByName(‘foo‘).length 返回 1（算入了 HTML 4 中不能带 name 但 id 与查询的name相同的div）
  • document.getElementsByName(‘bar‘).length 返回 1，是正常行为。

FireFox 与 Chrome 返回 1，0，1，即允许任意元素带 name，且不会将 id 与 name混淆。

因此在IE 9-下，使用该方法获取的元素可能还需要用 elem.name == name 进行过滤。

此外，某些IE版本返回的不是NodeList，HTMLCollection，不过因为HTMLCollection兼容NodeList，所以没有大碍。

其他

在 DOM HTML 里，name 只出现在一部分元素的IDL里（有哪些元素的IDL里带有attribute DOMString name 可参见 DOM Level 2 和 WHATWG，或者参考HTML4 DTD），而其他元素的name实际上是作为一个普通的Attr Node 而不是元素IDL里本身带的属性，通过NamedNodeMap实现的（参见DOM 3 和 WHATWG）。因此对于IDL里没有name的元素，不能直接用elem.name 获取name，但用getAttribute则都可以获取。例如：

<!DOCTYPE html><html lang="en"><head>    <meta charset="UTF-8">    <title>Document</title></head><body>    <div name="baz"></div>    <a name="bar"></a></body></html>

在 console 里：

var div = document.getElementsByName(‘baz‘)[0];div.name; // undefineddiv.getAttribute(‘name‘); // bazvar a = document.getElementsByName(‘bar‘)[0];a.name; // bara.getAttribute(‘name‘); // bar

Webkit 代码分析

Document 继承 ContainerNode （见WebCore/dom/Document.h），实质上使用了ContainerNode的getElementsByName。

ContainerNode的getElementsByName使用NameNodeList作为NodeListsNodeData::addCacheWithAtomicName<>的template specialization （见WebCore/dom/ContainerNode.cpp）。注意NodeListsNodeData::addCacheWithAtomicName<>的模板提高了代码的重用——只需要为template specialization的类定义create、elementMatches等函数，即可使用addCacheWithAtomicName实现live的NodeList的过滤+缓存。WebKit将这些函数都汇总在了CachedLiveNodeList这个类里，只要继承这个类，实现它和它继承的虚函数，就可以用于addCacheWithAtomicName的template specialization（参见WebCore/dom/LiveNodeList.h），建立一个带有缓存和特定过滤标准的NodeList。

NodeListsNodeData使用一个私有的NodeListAtomicNameCacheMap成员m_atomicNameCaches实现缓存。当addCacheWithAtomicName被调用时，首先检查是否已存在对应的缓存，若存在，用m_atomicNameCaches.fastAdd快速更新（参见WebCore/dom/NodeRareData.h（注意NodeListAtomicNameCacheMap本质上是一个hash map，参见typedef定义）。如果没有缓存，调用模版类的create函数创建新的模版类对象并返回，这里为NameNodeList。

NamedNodeList 继承 CachedLiveNodeList，CachedLiveNodeList的迭代器使用的collectionBegin()，collectionTraverseForward()等（见WebCore/dom/LiveNodeList.h）会遍历需要过滤的root node的后代，使用虚函数elementMatches过滤（参见WebCore/dom/LiveNodeList.h）。NamedNodeList实现的elementMatches以element.getNameAttribute() == m_name作为过滤标准（见WebCore/dom/NameNodeList.h）。

值得注意的是CachedLiveNodeList的elementMatches从LiveNodeList继承而来，而在LiveNodeList的原型里elementMatches的原型为virtual bool elementMatches(Element&) const = 0——仅仅是个虚函数，不需要inline（参见WebCore/dom/LiveNodeList.h），但是在NamedNodeList的实现里这个函数被 inline 了。众所周知虚函数的调用要查表会带来较高的开销，对于这样会被高频率调用的函数来说显然是不行的，这里其实是通过 inline 来绕过这个开销。注意 virtual 与 inline 不冲突的条件是编译器需要在编译时知道将这个虚函数做inline实现的类是什么（而不能像普通的virtual调用一样留到运行时确定），而CachedLiveNodeList里凡是调用elementMatches的地方都会有类似auto& nodeList = static_cast<const NodeListType&>(*this)的语句先利用模版确定自己的静态类型，然后再使用这个确定了静态类型的引用而不是this来调用elementMatches，所以不会冲突（这种写法名为Curiously Recurring Template Pattern，能够实现出所谓的static polymorphism来绕开虚函数调用的开销又达到虚函数调用的目的）。这样绕个大弯（用上模版）为虚函数添加 inline 通常是为了性能考虑，参见Stackoverflow上的相关问题，这里刚好符合应用场景——elementMatches注定会被频繁调用。毕竟getElementsByName经常会直接在document上执行，那就会遍历文档里所有的节点，每遍历一个就要调用一次elementMatches来过滤，那通常至少也是上百甚至上千上万的调用……同样地，在ElementDescendantIterator里几乎所有的方法（包括构造函数）都被inline了，就是因为它作为遍历单位会被频繁调用方法，所以需要 inline 来榨干性能（参见WebCore/dom/ElementDescendantIterator.h

其他值得注意的点：

  • webkit是通过对实现定义好的 flag 做位运算来设置和判断元素是否拥有某个属性的（比如name），用一个32位的整数来为ElementData保存数组长度和flag（参见WebCore/dom/ElementData.h，，这样省空间又省时间，并且能够对IDL定义的属性和自定义的属性一视同仁。
  • Node里也是通过事先定义好的 flag 位运算来得知衍生类类型的（而不是使用C++昂贵的RTTI），flag的定义参见WebCore/dom/Node.h
  • 另外对于IDL里含有name的元素，webkit实际上是包了一个element.getNameAttribute来返回name的，比如<a>参见 WebCore/html/HTMLAnchorElement.cpp。因此NamedNodeList的element.getNameAttribute()不管name在IDL里还是作为本身的属性都会一并将其返回，反映到上层就是getElementsByName()也不需要管name是否在IDL里。

跟随标准与Webkit源码探究DOM -- 获取元素之getElementsByName


联系
我们