Side navigation
#4668 closed enhancement (worksforme)
Opened May 18, 2009 06:19PM UTC
Closed October 29, 2010 09:35PM UTC
Last modified March 15, 2011 03:58PM UTC
new HTML5 input types not recognized by attr()
| Reported by: | jacobrask | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | 1.4 |
| Component: | attributes | Version: | 1.3.2 |
| Keywords: | form input html5 | Cc: | |
| Blocked by: | Blocking: |
Description
The input types url, email, search, etc are not returned properly with the attr() function. The correct values are returned when grabbed with getAttribute() and can be seen in the rendered source.
Attachments (1)
Change History (8)
Changed May 18, 2009 11:36PM UTC by comment:1
| component: | unfilled → core |
|---|---|
| keywords: | forms, input, html → form input html5 |
| priority: | major → minor |
| type: | bug → enhancement |
Changed May 19, 2009 07:20AM UTC by comment:2
Ok. I am getting the type, and if type == email or type == url on blur I run a validation function.
Changed May 20, 2009 02:44PM UTC by comment:3
I still think this is a bug though. Any other attribute, HTML 4.01 or not, is possible to get with attr(). The expected behaviour is to get the actual contents of the attribute specified. Something must happen (break) on jQuery's side to produce this, since it works in native JavaScript.
Changed May 21, 2009 01:54AM UTC by comment:4
It's a property-vs-attribute conflict;
.attr()tries to do people a favor and paper over those differences as much as possible. In general,
.attr()is getting the live DOM properties and not attributes.
There is some discussion of the gotchas in #4283 and #4281. I'm not sure whether HTML5 should be supported more like XHTML or HTML4 but it may be too soon to even tell what to do.
Changed August 08, 2009 03:42PM UTC by comment:5
Test case with input type is number: http://jsbin.com/odeto
Results:
- IE all -> fails
- FF all -> fails
- Opera 9 & 10 -> OK
- Chrome 3 -> OK
- Safari 4 -> OK
Changed October 27, 2009 12:42PM UTC by comment:6
More information, and perhaps a detection method:
http://diveintohtml5.org/detect.html#input-types
Recommended here:
http://groups.google.com/group/jquery-en/browse_frm/thread/43094243cdd7f7e5
Changed October 29, 2010 09:35PM UTC by comment:7
| component: | core → attributes |
|---|---|
| priority: | minor → low |
| resolution: | → worksforme |
| status: | new → closed |
I'm seeing 100% pass in browsers that actually support these input types.
The related behavior was originally reported in #4404 as a bug, but I'll change this to an enhancement.
Running through the test case with Firebug, it appears that Firefox is ignoring the invalid
attribute (it doesn't know HTML5 yet after all) and using the default value of "text" as the *property*.http://www.w3.org/TR/html401/interact/forms.html#h-17.4
Yes, DOM
gets the actual value of the attribute in the markup, but the element is behaving like in everything but Opera. (For example, an will also report "text".)I would think that once these browsers support HTML5 form elements they will return the correct values. What is the impact of the current behavior on the code you're writing?