天天看点
返回

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

按照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; // undefined
div.getAttribute('name'); // baz

var a = document.getElementsByName('bar')[0];
a.name; // bar
a.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里。
c++ 前端开发 html5 javascript DOM webkit
上一篇: 跟随标准与Webkit源码探究DOM -- 获取元素之getElementById
下一篇: 从html页面中抽取table表格数据

继续阅读