Skip to main content

Bug Tracker

Side navigation

#9132 closed feature (wontfix)

Opened May 05, 2011 08:18PM UTC

Closed June 07, 2011 06:53PM UTC

Last modified March 14, 2012 06:47AM UTC

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

Reported by: 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

Attachments (0)
Change History (15)

Changed May 05, 2011 09:03PM UTC by timmywil comment:1

component: unfiledselector
priority: undecidedlow
type: enhancementfeature

Changed May 05, 2011 09:11PM UTC by rwaldron comment:2

_comment0: \ \ I don't think this belongs in the core, at least until/unless we have html5 shim suppot1304629982745192

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

Changed May 05, 2011 10:38PM UTC by timmywil comment:3

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.

Changed May 22, 2011 07:27PM UTC by john comment:4

keywords: → 1.7-discuss

Nominating ticket for 1.7 discussion.

Changed May 22, 2011 08:59PM UTC by rwaldron comment:5

-1, These can easily be created as custom selectors:

Changed May 23, 2011 12:49AM UTC by jaubourg comment:6


Changed May 23, 2011 04:47AM UTC by timmywil comment:7

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

Changed May 23, 2011 04:21PM UTC by comment:8

+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.

Changed May 23, 2011 04:58PM UTC by comment:9

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

Changed May 24, 2011 09:50PM UTC by dmethvin comment:10

-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]

Changed June 03, 2011 02:01PM UTC by john comment:11

-1, No new selectors, please.

Changed June 04, 2011 10:16PM UTC by addyosmani comment:12


Changed June 05, 2011 09:52PM UTC by ajpiano comment:13

-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.

Changed June 06, 2011 02:57PM UTC by scottgonzalez comment:14

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

Changed June 07, 2011 06:53PM UTC by rwaldron comment:15

milestone: 1.next1.7
resolution: → wontfix
status: openclosed

Closing per 1.7 roadmap meeting resolution