首页
学习
活动
专区
工具
TVP
发布
社区首页 >问答首页 >带有ids的DOM树元素会成为全局变量吗?

带有ids的DOM树元素会成为全局变量吗?
EN

Stack Overflow用户
提问于 2010-08-08 20:24:44
回答 3查看 48.2K关注 0票数 408

在构思一个简单的HTMLElement包装器时,我偶然发现了以下适用于Internet Explorer和Chrome的包装器

对于在DOM树中具有ID的给定HTMLElement,可以使用其ID作为变量名来检索该div。所以对于像这样的div

代码语言:javascript
复制
<div id="example">some text</div>

Internet Explorer 8和Chrome中,您可以执行以下操作:

代码语言:javascript
复制
alert(example.innerHTML); //=> 'some text'

代码语言:javascript
复制
alert(window['example'].innerHTML); //=> 'some text'

那么,这是否意味着DOM树中的每个元素都被转换为全局名称空间中的变量呢?这是否也意味着可以在这些浏览器中使用它来替代getElementById方法?

EN

回答 3

Stack Overflow用户

回答已采纳

发布于 2010-08-08 21:03:06

应该发生的是,“命名元素”被添加为document对象的外观属性。这是一个非常糟糕的想法,因为它允许元素名称与document的真实属性发生冲突。

IE还添加了命名元素作为window对象的属性,这让情况变得更糟。这就更糟糕了,因为现在您必须避免使用documentwindow对象(或项目中的任何其他库代码)的任何成员来命名元素。

这也意味着这些元素作为类似全局的变量可见。幸运的是,在这种情况下,代码中的任何真正的全局varfunction声明都会隐藏它们,所以您不需要在这里过多地担心命名问题,但是如果您尝试对具有冲突名称的全局变量进行赋值,并且忘记将其声明为var,您将在IE中得到一个错误,因为它试图将值赋给元素本身。

通常认为省略var以及依赖命名元素在window上可见或作为全局变量是不好的做法。坚持使用document.getElementById,它得到了更广泛的支持,也更少模棱两可。如果你不喜欢这种类型,你可以用更短的名字来编写一个简单的包装器函数。无论哪种方式,使用id- to -element查找缓存都没有意义,因为浏览器通常会优化getElementById调用以使用快速查找;当元素更改id或从文档中添加/删除元素时,您得到的只是问题。

Opera复制了IE,然后WebKit加入了进来,现在既有以前未标准化的将命名元素放在document属性上的做法,也有以前只有IE才有的将它们放到window上的做法是being standardised by HTML5,它的方法是记录和标准化浏览器作者强加给我们的每一种可怕的做法,使它们永远成为网络的一部分。所以Firefox4也会支持这一点。

什么是“命名元素”?任何具有id的对象,以及任何具有用于“标识”目的的name的对象:即表单、图像、锚点和其他一些对象,但不是name属性的其他无关实例,如表单输入字段中的控件名称、<param>中的参数名称或<meta>中的元数据类型。为了支持id,应该避免使用“识别”name

票数 433
EN

Stack Overflow用户

发布于 2010-08-08 20:29:10

在这些情况下,您应该坚持使用getElementById(),例如:

代码语言:javascript
复制
document.getElementById('example').innerHTML

IE喜欢在全局名称空间中混合使用具有nameID属性的元素,因此最好明确说明您想要获得什么。

票数 21
EN

Stack Overflow用户

发布于 2019-02-06 11:18:09

这个问题听起来应该是::“具有所提供ID的HTML标记是否会成为全局可访问的DOM元素?”

答案是肯定的!

这就是它的工作方式,这也是W3C引入ID的原因:在经过解析的脚本环境中,HTML标记的ID成为其相应的DOM元素句柄。

然而,Netscape Mozilla拒绝遵守(向他们入侵) W3C,并顽固地继续使用过时的Name属性来制造混乱,从而破坏了W3C引入的唯一in带来的脚本功能和编码便利性。

在Netscape Navigator4.7惨败后,他们的开发人员都去渗透了W3C,而他们的同事却用错误的做法和滥用的例子取代了网络。强制使用和重用已经弃用的Name属性!这并不意味着与ID属性一样是唯一的,这样使用ID句柄访问特定DOM元素的脚本就会中断!

他们这样做了,因为他们还会编写和发布大量的编码课程和示例,他们的浏览器无论如何都不会识别,比如document.all.ElementID.property而不是ElementID.property,这至少会使其效率低下,并给浏览器带来更多开销,以防它没有简单地在HTML域中断它(现在1996-97,弃用)名称和为它提供相同标记值的标准ID属性。

他们轻而易举地说服了当时绝大多数无知的代码编写爱好者,让他们相信名称和ID实际上是相同的,只是ID属性更短,因此节省了字节,并且比古老的Name属性更方便编程。这当然是个谎言。或者-在他们发布的HTML文章中,令人信服的文章,你将需要为你的标签提供名称和ID,以便脚本引擎可以访问它们。

代号为"Mozilla“的马赛克杀手非常生气,他们认为”如果我们倒下了,互联网也应该倒下“。

另一方面,正在崛起的微软是如此天真,他们认为他们应该保留已弃用和标记为删除的名称属性,并将其视为唯一标识符的ID,这样他们就不会破坏Netscape见习生编写的旧页面的脚本功能。他们大错特错了。

返回ID冲突元素的数组集合也不能解决这个人为的问题。实际上,它违背了整个目的。

这就是W3C变得丑陋的唯一原因,并给我们带来了像document.getElementById这样的笨蛋以及伴随而来的洛可可他妈的讨厌的语法……(...)

票数 8
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/3434278

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档