考慮這個HTML源代碼：在IE和Opera中添加名稱屬性導致ID值成爲文檔對象的屬性？
<form id="foo1" name="x"> Form 1 </form>
<form id="foo2"> Form 2 </form>
正如你所看到的，我們定義了兩個表單元素。
在Chrome，Safari和Firefox中，document.foo1和document.foo2均返回undefined。
但是，在IE和Opera中，document.foo1返回對相應FORM元素的引用，而document.foo2返回undefined。
現場演示：http://jsfiddle.net/zrmEm/2/
所以，第一種形式確實有它的ID命名的屬性的文檔對象，第二個表格沒有。這種差異是將name屬性添加到第一種形式的結果。
現在，那裏的邏輯在哪裏？這是一個已知的行爲嗎？
在所有的瀏覽器，表單的名稱屬性的值被添加作爲文檔對象的屬性，並且還作爲document.formscollection的性質。
如果您使用的是ids，則這些值僅作爲表格集合的屬性添加。
IE總是對名稱和id屬性感到困惑。在IE（測試版本8）中，如果還有該表單的名稱（可能與id相同或不同），則會添加文檔的屬性。
所以，如果你總是使用document.forms ['name-or-id']那麼生活是甜蜜的。只要您沒有名稱與其他帶有ID的表單相同的表格，則所有投注都將關閉。
呃...你的回答是準確的，據我所知，你的表述比我的更好。所以我剛剛刪除了我的：P –
只是爲了補充一點，需要注意的是'id's和'name's駐留在相同的命名空間中。如果你有一個獨特的元素*應該*具有'name'屬性，'id'和'name'匹配是明智的。 – 2011-09-30 15:43:30
這基本上是微軟在瀏覽器戰爭黑暗時期推出的一種怪癖。 （大約IE4）
最終結果是，在IE中，表單將作爲變量添加到文檔範圍，以便您可以將它們引用爲document.form1。
這是非標準的，但當時似乎並不重要（至少對於瀏覽器供應商來說）並不重要。
當時添加到一個瀏覽器或另一個瀏覽器的許多非標準功能最終被別人實現，成爲事實上的標準，最終成爲官方標準。
然而，這個特殊功能沒有。它仍然是非標準的。
即使在較新版本的瀏覽器中，微軟仍舊保留了大部分舊的非標準功能，以努力保持舊代碼的向後兼容性（許多企業內部網由微軟培訓的「專家」編寫，並使用這些功能，所以他們需要保持它們，否則沒有人會永遠升級過去的IE6）。
在那些日子裏，Opera是瀏覽器世界的年輕僞裝者。它經常更新，具有創新功能，並且比競爭對手跑得快得多。他們當時正在爲瀏覽器世界做最近Chrome的做法。但是由於標準戰爭的不斷升級，Opera能夠競爭的唯一方式就是兼容，他們竭盡全力在IE中對所有功能進行反向工程（甚至在某些情況下還會出現bug），以便站點爲IE編寫的代碼也可以在Opera中使用。
這顯然是這些功能之一，這就是爲什麼IE和Opera今天都有共同的怪癖。
今天市場上的其他瀏覽器沒有相同的歷史。 Firefox最終來源於Netscape Navigator，儘管它可能有自己的怪癖可以追溯到那些日子，但它不會共享IE的。而webkit瀏覽器有更近期的出處（它來源於KDE Project的KHTML引擎），所以它再也沒有嘗試模擬IE的怪癖。
你應該簡單地忽略這些瀏覽器做的和不做的全局變量，因爲你不應該使用它們。他們不是標準的。使用'document.getElementById（）'獲得一個帶有id的對象的DOM引用。它不同於一個瀏覽器的原因是它不是由標準定義的。 – jfriend00
只是不要讓Google知道它，否則他們會將其添加到Chrome的下一個版本中。我的意思是他們已經得到了'document.all'和'window.event'的好處。似乎他們暗中想成爲IE！ – user113716
@Ӫ_._Ӫ爲時已晚。 Chrome瀏覽器（以及其他瀏覽器）確實添加了「遍佈全球」的窗口和文檔屬性。例如，對於上面的HTML代碼，Chrome會創建3個全局屬性：'window.foo1'，'window.foo2'和'window.x'，以及一個文檔屬性：'document.x'（所有這些都是對錶格）。這種全球命名空間污染至少可以說是令人不安的，但除了Firefox（!!）之外的所有瀏覽器都這樣做。 **演示：** http://jsfiddle.net/c4tTw/ –