Skip to main content

Bug Tracker

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)
  • inputjquery.html (1.1 KB) - added by jacobrask May 18, 2009 06:21PM UTC.

    html5 input types grabbed with JS and jQuery

Change History (8)

Changed May 18, 2009 11:36PM UTC by dmethvin comment:1

component: unfilledcore
keywords: forms, input, htmlform input html5
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?

Changed May 19, 2009 07:20AM UTC by jacobrask 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 jacobrask 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 dmethvin 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 jerone 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 dmethvin comment:6

Changed October 29, 2010 09:35PM UTC by rwaldron comment:7

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/

Changed March 15, 2011 03:58PM UTC by rwaldron comment:8

#8531 is a duplicate of this ticket.