#3917 closed bug (wontfix)
input maxLength property/attribute is not consistent
| Reported by: | webbower | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | 1.3.1 |
| Component: | core | Version: | 1.3 |
| Keywords: | attr input maxLength | Cc: | |
| Blocked by: | Blocking: |
Description
The example I found was trying to get the "maxlength" attribute from a text input element and if it was not set, the function returned "-1" instead of undefined like the documentation says. My Firebug helped me discover the actual result. I'm not sure if the bug exists when trying to get other attributes or if it also returns "-1" for other attributes that aren't set.
Mac OS X 10.5.6 Firefox 3.0.5 Firebug 1.2.1
Attachments (1)
Change History (5)
Changed 14 years ago by
| Attachment: | test-3917.html added |
|---|
comment:1 follow-up: 2 Changed 14 years ago by
| Keywords: | attr input maxLength added |
|---|---|
| Summary: | $(el).attr(name) does not return undefined if attritbute is not set in some cases → input maxLength property/attribute is not consistent |
This isn't consistent across browsers, or even across property vs. attribute. However, the behavior has not changed since 1.2.6. I've attached a test case. In FF3, the maxLength property is -1 and the maxLength attribute is null. In Ie the property is 2147483647 and the attribute is null. jQuery returns the property value in preference to the attribute, and the property value is defined.
comment:3 Changed 14 years ago by
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
Unfortunately we can't have it both ways. IE immediately converts the attribute to a property/expando and using the setAttribute/removeAttribute/getAttribute apis no long work.
Not sure we can normalize this without a large impact on performance.
comment:4 Changed 14 years ago by
If you can't fix the bug, then I'd recommend correcting the Docs to reflect the actual behavior.
maxLength property vs. attribute