Ticket #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: | |
| Blocking: | Blocked by: |
Description
We already have :text. For consistency we should add :email, :url, and :search
Change History
comment:1 Changed 2 years ago by timmywil
- Priority changed from undecided to low
- Type changed from enhancement to feature
- Component changed from unfiled to selector
comment:2 Changed 2 years ago by rwaldron
http://blogs.sitepoint.com/make-your-own-custom-jquery-selector/
I don't think this belongs in the core,until/unless we have html5 shim support
comment:3 Changed 2 years ago by timmywil
- Status changed from new to open
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 2 years ago by john
- Keywords 1.7-discuss added
Nominating ticket for 1.7 discussion.
comment:5 Changed 2 years ago by rwaldron
-1, These can easily be created as custom selectors: http://jsfiddle.net/rwaldron/W7PS4/
comment:7 Changed 2 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 2 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 2 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 2 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 2 years ago by john
-1, No new selectors, please.
comment:12 Changed 2 years ago by addyosmani
+0
comment:13 Changed 2 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 2 years ago by scott.gonzalez
+0, <3 custom selectors, but I understand that these aren't going to land...
comment:15 Changed 2 years ago by rwaldron
- Status changed from open to closed
- Resolution set to wontfix
- Milestone changed from 1.next to 1.7
Closing per 1.7 roadmap meeting resolution
Please follow the bug reporting guidlines and use jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.
