Side navigation
#7472 closed bug (fixed)
Opened November 11, 2010 11:43AM UTC
Closed April 10, 2011 08:01PM UTC
Last modified March 10, 2012 01:22AM UTC
$('form').attr('id') return DOM Element
Reported by: | pinal | Owned by: | |
---|---|---|---|
Priority: | low | Milestone: | 1.6 |
Component: | attributes | Version: | 1.5.2 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
If form has input with name="id" its id automatically become the input element.
Attachments (0)
Change History (7)
Changed November 11, 2010 02:25PM UTC by comment:1
resolution: | → patchwelcome |
---|---|
status: | new → closed |
Changed November 11, 2010 03:02PM UTC by comment:2
_comment0: | I are right about IE. I didn't wrote the browser, beacause bug is in all modern browsers (chrome 7,safari 5,opera 10.6*,ff 3.6.*) \ http://jsfiddle.net/ua4kZ/7/ - look \ $('form').attr('id') - return node \ $('form')[0].getAttribute('id') - return null → 1289487760284194 |
---|---|
_comment1: | I are right about IE. I didn't wrote the browser, beacause bug is in all modern browsers (chrome 7,safari 5,opera 10.6*,ff 3.6.*)[[BR]] \ http://jsfiddle.net/ua4kZ/7/ - look[[BR]] \ $('form').attr('id') - return node[[BR]] \ $('form')[0].getAttribute('id') - return null[[BR]] → 1289488541622922 |
Yoy are right about IE. I didn't wrote the browser, beacause bug is in all modern browsers (chrome 7,safari 5,opera 10.6*,ff 3.6.*)
http://jsfiddle.net/ua4kZ/7/ - look
$('form').attr('id') - return node
$('form')[0].getAttribute('id') - return null
Changed November 11, 2010 03:11PM UTC by comment:3
_comment0: | I think it will be right to get elem.nodeType for attribute and if nodeType !== 2, return null. So for form.id.nodeType will be equal 1 in my example.[[BR]] \ http://www.w3schools.com/Dom/dom_nodetype.asp[[BR]] \ NodeType Named Constant \ 1 ELEMENT_NODE \ 2 ATTRIBUTE_NODE → 1289488340854321 |
---|
I think it will be right to get elem.nodeType for attribute and if nodeType !== 2, return null. So for form.id.nodeType will be equal 1 in my example.
http://www.w3schools.com/Dom/dom_nodetype.asp
NodeType Named Constant
1 ELEMENT_NODE
2 ATTRIBUTE_NODE
Changed November 11, 2010 03:30PM UTC by comment:4
This is a well known problem (References)\\\\
Deadly Expandos\\\\
Unsafe Names for HTML Form Controls
The problem comes from the old DOM 0/DOM 1 days. DOM 1 HTML states
>The FORM element encompasses behavior similar to a collection and an element. It provides direct access to the contained input elements as well as the attributes of the form element.
And basically all browsers still do that as many scripts rely on this behavior. jQuery has already fixed many of the problems this brings when working with form (e.g. recently #7212)
But I'm not really sure we should fix it for attr()
. When an explicit id
is specified on the form jQuery returns that, if no id is specified attr()
returns the element with id/name = id
But your idea for a fix to check for nodeType
or nodeName
is interesting. I don't know if this fits well into jQuery/Sizzle core but it could be documented on attr()
api docs.
Changed April 10, 2011 08:01PM UTC by comment:6
milestone: | 1.5 |
---|---|
resolution: | patchwelcome |
status: | closed → reopened |
Changed April 10, 2011 08:01PM UTC by comment:7
component: | unfiled → attributes |
---|---|
milestone: | → 1.6 |
priority: | undecided → low |
resolution: | → fixed |
status: | reopened → closed |
version: | 1.4.4rc → 1.5.2 |
If I remember correctly, some IEs get confused in forms when you have names that conflict with attribute types, since IE gives you the option of traversing a form via the element names as expandos. This is not the case in most modern browsers.
I believe the best solution is to avoid using attribute names and your name value. We could potentially find a work-around to this problem and get it in, but at the cost of performance and file-size that probably aren't worth the fix.
If you have a patch for this that you'd like us to consider, we'd be happy to work with you on it, and then ultimately see if it would make sense to go into the library, but for now, I think we're intentionally not working on this, due to obscurity and ease of a workaround.