Bug Tracker

Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#9132 closed feature (wontfix)

Add pseudo selectors for new HTML5 input types e.g. :email, :search, etc.

Reported by: adamzr@… Owned by:
Priority: low Milestone: 1.7
Component: selector Version: 1.6
Keywords: 1.7-discuss Cc:
Blocked by: Blocking:


We already have :text. For consistency we should add :email, :url, and :search

Change History (15)

comment:1 Changed 8 years ago by timmywil

Component: unfiledselector
Priority: undecidedlow
Type: enhancementfeature

comment:2 Changed 8 years ago by Rick Waldron


I don't think this belongs in the core,until/unless we have html5 shim support

Last edited 8 years ago by Rick Waldron (previous) (diff)

comment:3 Changed 8 years ago by timmywil

Status: newopen

For now you can also do $('input[type="email"]'), but IE converts types it doesn't understand to text, which makes a filter like more troublesome.

comment:4 Changed 8 years ago by john

Keywords: 1.7-discuss added

Nominating ticket for 1.7 discussion.

comment:5 Changed 8 years ago by Rick Waldron

-1, These can easily be created as custom selectors: http://jsfiddle.net/rwaldron/W7PS4/

comment:6 Changed 8 years ago by jaubourg


comment:7 Changed 8 years ago by timmywil

-1, plugin, if needed. and there's the question of should it fall back to text if not supported or not return anything?

comment:8 Changed 8 years ago by adamzr@…

+1, We should also decide if :text should return type=email on older browsers. To new programmers who started with HTML5 that behavior is just as confusing. We should just add to the docs that that :text may return other input elements on older browsers.

In my opinion, if we have one of these filters built in we should have all of them. True, they can be easily added with a plug-in or a custom selector, but so could :text and we have that. This kind-of basic functionality is useful and should be built-in. While its behavior is weird on older browsers, that is already true for :text and can be documented.

comment:9 Changed 8 years ago by paul.irish

-1, without also detecting browser support for each input type, you're probably going to make the wrong choice.

comment:10 Changed 8 years ago by dmethvin

-1, Read my lips, no new selectors. For consistency, Sizzle should select only text inputs with [type=text] and select only email elements for [type=email]

comment:11 Changed 8 years ago by john

-1, No new selectors, please.

comment:12 Changed 8 years ago by addyosmani


comment:13 Changed 8 years ago by ajpiano

-1, I understand adamzr's reply, but as Dave and John indicate above, we are very resistant to add custom selectors because they force us to take slow paths and general create a number of other headaches. We can't drop the existing selectors, which have existed obviously since before these HTML5 elements were really kicking around - but that alone does not mean we are realistically able or want to continue adding more.

comment:14 Changed 8 years ago by scottgonzalez

+0, <3 custom selectors, but I understand that these aren't going to land...

comment:15 Changed 8 years ago by Rick Waldron

Milestone: 1.next1.7
Resolution: wontfix
Status: openclosed

Closing per 1.7 roadmap meeting resolution

Note: See TracTickets for help on using tickets.