例如处理事件的时候,有时候需要知道当前点击的是第几个子节点,而HTML DOM本身并没有直接提供相应的属性,需要自己来计算。
从一个索引序号,很容易得到该索引对应的子节点或者子元素,直接用parentNode.childNodes[index] 或 parentNode.children[index] 就行。
但反过来,已知一个节点或元素对象,要知道它的索引序号则没有那么直接了。
一些特殊的元素,HTML DOM有对应的属性表示其索引序号,主要是表格的TD 和 TR 元素。
表格单元格TD元素有 cellIndex 属性。
表格行TR元素有rowIndex属性。
如果你的处理目标刚好就是表格,则优先使用这两个属性。
但一般的节点或元素并没有 childNodeIndex 或者 childElementIndex 之类的属性。
解决方案主要分为两类:
一、预先计算并缓存节点的索引号(可以存在节点属性或者js变量中)。
二、实时计算,需要遍历部分节点。
应用中,可根据不同的实际情况,选用上述两类方案之一。
适用方案一的情形:
当DOM结构不会变化,并且需要频繁的获取个别节点的索引,可采用方案一。
优点是后续读取快,缺点是初始化需要开销,DOM结构变化后需要重新初始化。
适用方案二的情形:
DOM结构可能会变化,并且不是特别频繁的获取个别节点的索引,可采用方案二。
优点是不受DOM结构变化的影响,不会污染DOM结构,没有初始化开销。缺点是不适合高频率调用。
一般而言,采用方案二是更好的,因为通常DOM树规模是比较有限的,一轮的循环并不会导致显著降低整体性能,而其优点则是显著的。
对于IE浏览器,则有更直接的方法。
从IE4到IE11,都有sourceIndex属性,这个属性表示了元素在DOM树的顺序,比较元素和父元素的sourceIndex的差值就很容易知道元素是第几个子元素了。
我写了一段函数来区分处理,在IE下采用sourceIndex高效判断,非IE则采用一般遍历。
复制代码 代码如下:
function getChildrenIndex(ele){
//IE is simplest and fastest
if(ele.sourceIndex){
return ele.sourceIndex - ele.parentNode.sourceIndex - 1;
}
//other browsers
var i=0;
while(ele = ele.previousElementSibling){
i++;
}
return i;
}
上面的函数只是计算元素Element,也就是nodeType为1的节点,文本节点、注释节点等将不被统计。如果需要计算所有节点在内,则不能适用sourceIndex,因为该属性只针对Element. previousElementSibling也要相应的改为previousSibling. 那就要写成如下的函数了:
复制代码 代码如下:
function getNodeIndex(node){
var i=0;
while(ele = ele.previousSibling){
i++;
}
return i;
}
后记:在非IE下,有 compareDocumentPosition 方法用于比较节点的位置关系,但经过测试该方法的性能非常差,其内部的实现机制肯定不是像IE那样缓存了资源索引号的,如果这个方法极高效,那就可采用二分法进行计算,从而提高效率,但目前还不可能。
最后的总结:
对于表格TD和TR元素优先使用cellIndex和rowIndex属性。
对于IE优先使用sourceIndex属性。
其它情形使用previousElementSibling 或 previousSibling 进行遍历。
compareDocumentPosition 方法的性能非常差。
从一个索引序号,很容易得到该索引对应的子节点或者子元素,直接用parentNode.childNodes[index] 或 parentNode.children[index] 就行。
但反过来,已知一个节点或元素对象,要知道它的索引序号则没有那么直接了。
一些特殊的元素,HTML DOM有对应的属性表示其索引序号,主要是表格的TD 和 TR 元素。
表格单元格TD元素有 cellIndex 属性。
表格行TR元素有rowIndex属性。
如果你的处理目标刚好就是表格,则优先使用这两个属性。
但一般的节点或元素并没有 childNodeIndex 或者 childElementIndex 之类的属性。
解决方案主要分为两类:
一、预先计算并缓存节点的索引号(可以存在节点属性或者js变量中)。
二、实时计算,需要遍历部分节点。
应用中,可根据不同的实际情况,选用上述两类方案之一。
适用方案一的情形:
当DOM结构不会变化,并且需要频繁的获取个别节点的索引,可采用方案一。
优点是后续读取快,缺点是初始化需要开销,DOM结构变化后需要重新初始化。
适用方案二的情形:
DOM结构可能会变化,并且不是特别频繁的获取个别节点的索引,可采用方案二。
优点是不受DOM结构变化的影响,不会污染DOM结构,没有初始化开销。缺点是不适合高频率调用。
一般而言,采用方案二是更好的,因为通常DOM树规模是比较有限的,一轮的循环并不会导致显著降低整体性能,而其优点则是显著的。
对于IE浏览器,则有更直接的方法。
从IE4到IE11,都有sourceIndex属性,这个属性表示了元素在DOM树的顺序,比较元素和父元素的sourceIndex的差值就很容易知道元素是第几个子元素了。
我写了一段函数来区分处理,在IE下采用sourceIndex高效判断,非IE则采用一般遍历。
复制代码 代码如下:
function getChildrenIndex(ele){
//IE is simplest and fastest
if(ele.sourceIndex){
return ele.sourceIndex - ele.parentNode.sourceIndex - 1;
}
//other browsers
var i=0;
while(ele = ele.previousElementSibling){
i++;
}
return i;
}
上面的函数只是计算元素Element,也就是nodeType为1的节点,文本节点、注释节点等将不被统计。如果需要计算所有节点在内,则不能适用sourceIndex,因为该属性只针对Element. previousElementSibling也要相应的改为previousSibling. 那就要写成如下的函数了:
复制代码 代码如下:
function getNodeIndex(node){
var i=0;
while(ele = ele.previousSibling){
i++;
}
return i;
}
后记:在非IE下,有 compareDocumentPosition 方法用于比较节点的位置关系,但经过测试该方法的性能非常差,其内部的实现机制肯定不是像IE那样缓存了资源索引号的,如果这个方法极高效,那就可采用二分法进行计算,从而提高效率,但目前还不可能。
最后的总结:
对于表格TD和TR元素优先使用cellIndex和rowIndex属性。
对于IE优先使用sourceIndex属性。
其它情形使用previousElementSibling 或 previousSibling 进行遍历。
compareDocumentPosition 方法的性能非常差。
广告合作:本站广告合作请联系QQ:858582 申请时备注:广告合作(否则不回)
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
暂无评论...
更新日志
2024年11月25日
2024年11月25日
- 凤飞飞《我们的主题曲》飞跃制作[正版原抓WAV+CUE]
- 刘嘉亮《亮情歌2》[WAV+CUE][1G]
- 红馆40·谭咏麟《歌者恋歌浓情30年演唱会》3CD[低速原抓WAV+CUE][1.8G]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[320K/MP3][193.25MB]
- 【轻音乐】曼托凡尼乐团《精选辑》2CD.1998[FLAC+CUE整轨]
- 邝美云《心中有爱》1989年香港DMIJP版1MTO东芝首版[WAV+CUE]
- 群星《情叹-发烧女声DSD》天籁女声发烧碟[WAV+CUE]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[FLAC/分轨][748.03MB]
- 理想混蛋《Origin Sessions》[320K/MP3][37.47MB]
- 公馆青少年《我其实一点都不酷》[320K/MP3][78.78MB]
- 群星《情叹-发烧男声DSD》最值得珍藏的完美男声[WAV+CUE]
- 群星《国韵飘香·贵妃醉酒HQCD黑胶王》2CD[WAV]
- 卫兰《DAUGHTER》【低速原抓WAV+CUE】
- 公馆青少年《我其实一点都不酷》[FLAC/分轨][398.22MB]
- ZWEI《迟暮的花 (Explicit)》[320K/MP3][57.16MB]