Side navigation
#8565 closed bug (duplicate)
Opened March 18, 2011 05:47PM UTC
Closed March 20, 2011 10:02PM UTC
Last modified March 20, 2011 10:02PM UTC
'input:text' selector not finding input elements with no type attribute
Reported by: | fasteater | Owned by: | |
---|---|---|---|
Priority: | undecided | Milestone: | 1.next |
Component: | unfiled | Version: | 1.5.1 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
As recently as 1.4.3 $('input:text') would find input elements with no type attribute (type=text is the default if no type is defined), but after upgrading to 1.5.1 that is no longer the case.
FYI - this is the selector I now have to use: $('input:text, input:not([type])')
This repros for me in FF3.6 and Chrome 10.0.648.134. IE7 and IE8 work as expected (for a change).
Test case: http://jsfiddle.net/KJL8q/
Attachments (0)
Change History (5)
Changed March 18, 2011 06:03PM UTC by comment:1
Changed March 18, 2011 08:33PM UTC by comment:2
Although this is a relatively minor fix, in my opinion this is a case of invalid input = invalid output. If people wish to use input elements correctly a valid type should definitely be specified.
Changed March 18, 2011 10:31PM UTC by comment:3
While I agree that specifying the type is best-practice, it is not invalid to not list it. In fact, the HTML spec doesn't define the type attribute as required, only that type defaults to "text" (something that jQuery relies on for newer HTML5 types in older browsers).
Changed March 20, 2011 10:02PM UTC by comment:4
resolution: | → duplicate |
---|---|
status: | new → closed |
The problem is that the W3C specifies that if the type
is not understood by the browser then it defaults to text
. So if you have <input type="number" />
it will have a type *property* of number
in HTML5-aware browsers but text
in non-HTML5 browsers like IE8 or Firefox 3.
There is a fix going into 1.5.2 that will address the specific issue here, but I still think that explicitly specifying a type *attribute* is strongly recommended.
This is my proposed fix to the text filter (line 3920):