再贴一次form的属性和控件name冲突的老问题

更新：
John Resig也谈到了这个问题。
而这里是一个非常详尽的分析。

本来要是给realazy写的form 元素内的字段 name 不要跟 form 属性名称一致的comment，但是大概是给出链接太多，被认为是spam的缘故，所以发不出来，只好在这里再贴一次。


这个问题不仅是IE的问题，其他浏览器也是如此。
我提交到mozilla的bug：
https://bugzilla.mozilla.org/show_bug.cgi?id=322488

（我用蹩脚的英文分析了这为什么是一个bug，以及提出了折衷解决方法，不过至今没人睬我 -_-凸，所以这个bug的状态始终是unconfirmed）

全文如下：
DOM level 0 support access form controls via such script:
var f = document.forms[0];
var control1 = f['controlNameOrId'];
var control2 = f.controlNameOrId;

Though DOM HTML spec provide HTMLFormElement.elements to replace this approach,
but MSIE and Firefox still remain this problematic feature.

The issue here is named control may override the attribute or method of
HTMLFormElement. For example, if there is <input name="action" /> in the form,
then document.forms[0].action will return that HTMLInputElement. And there is a
bizarre behavior in firefox that assign still works

document.forms[0].action = 'http://url'
alert(document.forms[0].action == 'http://url')
document.forms[0].submit()

the 1st line is ok in Firefox(but failed in MSIE), but I find no way to
retrieve it back. the 2nd line will alert false, but u still submit to
http://url (if there is no control named 'submit'

Such behavior is undocumented (maybe i missed...), and will confuse developers
if they unfortunately meet some controls named 'method', 'length', 'id',
'item'(IE only), 'target', 'elements'...

To make the script works, especially when you write a reused component or
script library, there should be no such uncontrolled name conflict. But in most
case the web page is written by designer who has no concern about script, so
it's hard to avoid such case. And, even a script master won't remember all
attribute/method of HTMLFormElement.

As a conclusion, form['controlName'] approach should be removed or limited(ie.
won't override the attribute/method of HTMLFormElement).


javaeye也有人曾提及这个问题：http://yipsilon.iteye.com/blog/136211
更新：http://anweixiao.iteye.com/blog/86997也描述了所遇到的问题：名为submit的控件会遮蔽form.submit()方法。

这里是CSDN以前的讨论（注意大多数回复都是垃圾，只看我写的就好 -_-# 汗）：
http://topic.csdn.net/t/20060118/23/4524484.html

我所知最早提到这个问题的：
http://dulao5.blog.hexun.com/1398177_d.html

最后是我以前写的分析：
http://blog.csdn.net/hax/archive/2006/01/06/571658.aspx
全文如下：

因兼容DOM0的关系，form被设计成支持直接可通过name直接access到control。例如如有一个<input name="user"/>则可直接使用形如document.forms[0]["user"]，或在没有特殊字符的情况下，可以直接document.forms[0].user。

然而这造成一个问题，即name若与form上的方法或属性冲突的话（例如form具有length属性，而同时给form增加一个name为length的控件），会如何？

经过我的测试，在IE（XP下的6.0）和FireFox（1.5）中，name都会覆盖原来的属性或方法。也就是优先向前兼容。

作为一种权衡，这种做法本无确定的好坏。但问题是这种行为，在编写脚本中，name与方法冲突下，会产生令developer意想不到的奇怪行为。而且没有在我看到的任何文档中记录。（或许我孤陋寡闻，有方法可以避免？）特别是在IE中，对于Element和一些内置方法的toString()居然都不负责任的返回“[object]”，一旦发生问题，完全令人毫无头绪。

比如，我正好有个脚本要检测form中是否含有特定name的control，而IE的form恰好有个额外的item方法，结果是我必须为此特别处理：

control = myForm[name];
if (typeof control == "undefined" ||
  (name == "item" && control == "[object]"))
  ...

当然，实际上我应该为所有form的属性和方法做特别检测。

显然，为了脚本能正常运行，不应该允许任何name的屏蔽（试想name为action、method、submit、reset等的情况）。然而要网页设计者记住一大堆应为form scripting保留的名字是不现实的。

所以结论是：这种向前兼容是错误的设计决策。

评论

3 楼 hax 2009-09-21  

9月11日，此bug终于被标记为了NEW。

2 楼 shqlsl 2008-11-08  

当你<input name="submit"/>
会照片 form.submit() 不能工作。
因为 submit 被认为是一个Input of Element.而不是一个事件。
我之前遇到过。
经常遇到这个 问题比较多如：
http://anweixiao.iteye.com/blog/86997

1 楼 zbm2001 2008-11-08  

比较赞同你的观点，
这个历史遗留问题处理的不严谨，
并且似乎也找不出什么很特别的理由来让它继续遗留下去。