#4668 closed enhancement (worksforme)
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 (9)
Changed 14 years ago by
Attachment: | inputjquery.html added |
---|
comment:1 Changed 14 years ago by
Component: | unfilled → core |
---|---|
Keywords: | form html5 added; forms html removed |
Priority: | major → minor |
Type: | bug → enhancement |
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 type
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 .getAttribute()
gets the actual value of the attribute in the markup, but the <input>
element is behaving like type="text"
in everything but Opera. (For example, an <input type="quirky">
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?
comment:2 Changed 14 years ago by
Ok. I am getting the type, and if type == email or type == url on blur I run a validation function.
comment:3 Changed 14 years ago by
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.
comment:4 Changed 14 years ago by
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.
comment:5 Changed 14 years ago by
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
comment:6 Changed 13 years ago by
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
comment:7 Changed 12 years ago by
Component: | core → attributes |
---|---|
Priority: | minor → low |
Resolution: | → worksforme |
Status: | new → closed |
I'm seeing 100% pass in browsers that actually support these input types.
html5 input types grabbed with JS and jQuery