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

[[email protected]…]

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

[Rick Waldron]

​http://blogs.sitepoint.com/make-your-own-custom-jquery-selector/

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

[timmywil]

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.

[john]

Nominating ticket for 1.7 discussion.

[Rick Waldron]

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

[jaubourg]

+0,

[timmywil]

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

[[email protected]…]

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

[paul.irish]

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

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

[john]

-1, No new selectors, please.

[addyosmani]

+0

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

[scottgonzalez]

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

[Rick Waldron]

Closing per 1.7 roadmap meeting resolution