Question

我开始使用的所有浏览器都允许通过简单地写入id="myDiv"来访问元素：

myDiv

见这里：http://jsfiddle.net/L91q54Lt/

无论如何，这种方法似乎记录很差，事实上，我遇到的消息来源甚至没有提及它，而是假设一个人会使用

document.getElementById("myDiv")

或者

document.querySelector("#myDiv")

即使在事先知道其ID（即未在运行时计算）时也访问DOM元素。我可以说，如果有人无意中试图在更广泛的范围内重新定义myDiv（虽然不是这么好的想法......），后者的方法具有保持代码安全的优点，用一些不同的值覆盖它并且去没有注意到冲突。

但其他那个？除了代码设计之外，使用上面的简短表格是否有任何问题，或者我在这里缺少什么？

Answer 1

无论如何，这种方法似乎记录得很差，事实上，我遇到的消息来源甚至没有提及[...]

除了隐含声明的全局变量之外，缺乏文档是不使用它的一个重要原因。

~~将id值明显提升为全局变量并不符合标准（HTML5 spec for the ID attribute并未提及），因此，您不应该这样做。假设未来的浏览器将实现它。~~

编辑：事实证明此行为符合标准 - 在HTML5中，window应支持对＆＃34;命名元素的属性访问＆＃34;：

出于上述算法的目的，具有名称名称的命名对象是：


活动文档的子浏览上下文，其名称为 name ，

a，applet，area，embed，form，frameset，img或具有的对象元素   名称内容属性，其值为 name 或

具有 id 内容属性，其值为 name 的HTML元素。

来源：HTML 5 spec, 'Named access on window object"，强调我的。

基于此，标准合规性不是避免这种模式的理由。但是，规范本身建议不要使用它：

作为一般规则，依赖于此将导致代码脆弱。哪一个最终映射到此API的ID可能随着时间的推移而变化，就像新功能一样例如，添加到Web平台。而不是这个，使用 document.getElementById()或document.querySelector()。

Answer 2

好问题。正如爱因斯坦可能没有说的那样，事情应尽可能简单，并不简单。

如果有人无意中试图在更广泛的范围内重新定义myDiv（虽然不是这么好的想法......），后一种方法具有保持代码安全的优点，用一些不同的值覆盖它并继续而没有注意到冲突

这就是为什么这是一个坏主意的主要原因，而且这已经足够了。全局变量不能安全依赖。它们可以随时被任何最终在页面上运行的脚本覆盖。

除此之外，仅输入myDiv不是document.getElementById()的“简短形式”。它是对全局变量的引用。如果元素不存在，document.getElementById()将很乐意返回null，而尝试访问不存在的全局变量将引发引用错误，因此您需要将您对try / catch块中的全局引用包装起来是安全的。

这就是为什么jQuery如此受欢迎的一个原因：如果你做$("#myDiv").remove()，并且没有id为myDiv的元素，则不会抛出任何错误 - 代码只会默默地做什么，这通常是您在进行DOM操作时所需要的。

Answer 3

有几个原因：

您不希望您的代码和标记结合在一起。

通过使用特定的来电访问div，您不必担心全局空间被破坏。添加一个在全球空间中声明myDiv的库，您将陷入一个难以修复的痛苦世界。

您可以按ID访问不属于DOM的元素

它们可以位于片段，框架或已分离但尚未重新附加到DOM的元素中。

编辑：按ID

访问非附加元素的示例

＆＃13;

var frag = document.createDocumentFragment();
var span = document.createElement("span");
span.id = "span-test";
frag.appendChild(span);
var span2 = frag.getElementById("span-test");
alert(span === span2);

＆＃13;

Answer 4

就我而言，我的页面内有一个iframe。我对id属性和name属性感到困惑，这两个属性都影响到一个名为inner_iframe的变量，可以从window访问它！

如果仅使用 id属性，例如id="inner_iframe"，则window.inner_iframe是HTMLIFrameElement。属性包括inner_iframe.contentDocument和inner_iframe.contentWindow as described here *
- 在这种情况下，由于quoted by @joew in the accepted answer的原因，我假设变量出现在window上：
  
  具有 id 内容属性的HTML元素，其值为name
如果仅使用 name属性，例如name="inner_iframe"，则window.inner_iframe是一个“框架”，也就是"window object"。 contentWindow，因此名称属性inner_iframe 不具有属性contentDocument或contentWindow。
- 我假设quoted by @joew in the accepted answer是inner_iframe变量出现在window上的原因
  
  名称为名称
  的活动文档的
  子浏览上下文
如果我同时使用了和name和id属性，则我给两个属性赋予了相同的值name="inner_iframe" id="inner-iframe"； name属性胜过/夸大id属性；我只剩下“窗口对象”，而不是HTMLIFrameElement的！

所以我的意思是要注意歧义；具有两个不同API的同一对象上的name和id属性之间的冲突：这只是一种特殊情况，隐式行为和对窗口变量的附加可能会使您感到困惑。

*（并且仅在<script>在HTML中的<iframe>之后/之下加载，或者<script>等到window.onload之后才尝试通过id属性访问））

**此“框架”与DOM元素的区别在Mozilla文档中描述为：

window.frames伪数组中的每一项代表与给定或内容相对应的窗口对象，不是（i）frame DOM元素（即window.frames [ 0]与document.getElementsByTagName（“ iframe”）[0] .contentWindow）相同。

为什么我们不在JavaScript中使用元素ID作为标识符？

4 个答案: