Bug Tracker

Modify

Ticket #4668 (closed enhancement: worksforme)

Opened 4 years ago

Last modified 2 years ago

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:
Blocking: Blocked by:

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

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

Change History

Changed 4 years ago by jacobrask

html5 input types grabbed with JS and jQuery

comment:1 Changed 4 years ago by dmethvin

  • Keywords form input html5 added; forms, input, html removed
  • Priority changed from major to minor
  • Component changed from unfilled to core
  • Type changed from bug to 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 4 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 4 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 4 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 4 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:6 Changed 4 years ago by dmethvin

comment:7 Changed 3 years ago by rwaldron

  • Priority changed from minor to low
  • Resolution set to worksforme
  • Status changed from new to closed
  • Component changed from core to attributes

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

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

comment:8 Changed 2 years ago by rwaldron

#8531 is a duplicate of this ticket.

Please follow the  bug reporting guidlines and use  jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

View

Add a comment

Modify Ticket

Action
as closed
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.