Bug Tracker

Opened 10 years ago

Closed 9 years ago

Last modified 8 years ago

#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)

inputjquery.html (1.1 KB) - added by jacobrask 10 years ago.
html5 input types grabbed with JS and jQuery

Download all attachments as: .zip

Change History (9)

Changed 10 years ago by jacobrask

Attachment: inputjquery.html added

html5 input types grabbed with JS and jQuery

comment:1 Changed 10 years ago by dmethvin

Component: unfilledcore
Keywords: form html5 added; forms html removed
Priority: majorminor
Type: bugenhancement

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 10 years ago by jacobrask

Ok. I am getting the type, and if type == email or type == url on blur I run a validation function.

comment:3 Changed 10 years ago by jacobrask

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 10 years ago by dmethvin

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 10 years ago by jerone

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:7 Changed 9 years ago by Rick Waldron

Component: coreattributes
Priority: minorlow
Resolution: worksforme
Status: newclosed

I'm seeing 100% pass in browsers that actually support these input types.

http://jsfiddle.net/rwaldron/gSH8g/2/

comment:8 Changed 8 years ago by Rick Waldron

#8531 is a duplicate of this ticket.

Note: See TracTickets for help on using tickets.