当人们说对不同的DOM元素使用相同的id是错误的时候，我完全同意。我的意思是，甚至没有什么可讨论的。
但实际上，“如果你在页面上有几个同名的id，那就不能保证工作”这句话实际意味着什么？
实际上什么不保证有效？我们可以将ID视为常规属性，因此，我们可以找到document.querySelectorAll('[id="container"]')的所有div。通过getAttribute / setAttribute访问也应该可以正常工作。如果我们试图通过document.getElementById获取一个元素 - 好吧，我还没有测试过，但很可能选择器引擎会返回它找到遍历树的第一个元素。我可以想象这不能得到保证。还有什么？
CSS工作得很好 - #container {background-color: "red"}会用红色绘制所有找到的容器（或者我错了）。有人可以告诉我在标准规格中哪些行为无法保证？
那么，实际上并不能保证什么？我再一次承认使用相同的ID是错误的。我也不想讨论应用id-heavy css规则的性能问题。问题是与C / C ++程序员称之为“不可预测的行为”非常相似的东西。
UPD：如果听起来很难甚至是愚蠢的话，那么，只需在特定浏览器中提供不可预测的ID相关行为的示例。至少，对我来说，这是一个更有用的答案，而不是“嗯，任何事都不能保证，你怎么能得到它！”。
答案 0 :(得分：3)
如果某个实现拒绝完全使用包含重复ID的文档，或者忽略声明它的元素的所有中的乘法ID，或者返回<来自getElementById的元素的em> random 。它甚至可能是每次通话中的一个不同的随机元素。
有人可以告诉我在标准规格中哪些行为无法保证吗？
这不是它的工作原理。如果不能保证，那么规范中的无处不在是无法保证的。只有在规范的某个地方才能保证你可以指出明确的保证。否则，规范中无法保证，这意味着它无法保证。
答案 1 :(得分：3)
规范说ID应该是唯一的。
这意味着浏览器本身没有义务实现可以支持多个非unquie ID的代码。它可以假设在构建DOM模型时，id是唯一的并且可用作键。它们今天可能在某些浏览器中工作。但也许明天他们不会。仅仅因为它们发生在您测试的浏览器中运行，并不意味着它们将在未来的版本中运行，或者它们以不同的不可重复的方式表现。
也许第一次在星期一的文档上加载页面.getElementById可能会返回第一个元素，如果它是在星期二下午5点之后并且它在SSL站点上，则可能是document.getElementById会抛出异常。也许新版本的firefox不会将css属性应用于id首次出现之后的任何内容。谁知道。浏览器开发人员不必关心，这就是“无法保证工作”的意思。
答案 2 :(得分：1)
这是一个显示一些选择器怪癖的jsfiddle：http://jsfiddle.net/DmEmJ/
规范：
id = name [CS]
此属性为元素指定名称。该名称在文档中必须是唯一的。
如果您想要一个非唯一句柄，请使用类。这就是它们的用途。