Available selectors don’t meet developer needs #3

paulirish opened this Issue Oct 20, 2011 · 7 comments


None yet

7 participants


jQuery created a lot of sugar selectors that make finding relevant elements easier. It is now recommending against using many of them as they take a slow path and cannot leverage querySelectorAll. Selectors Level 4 should capture the selectors most used by jQuery developers.

Action Items

  • Identify what selectors in jQuery are in use and are currently not captured in Selectors Level 4



Raynos commented Oct 25, 2011

We should differentiate between selectors that are useful and difficult to emulate with the current selector api and selectors which are useful and easy to emulate.

An example would be the :checkbox which although useful as sugar is the same as [type='checkbox']. So the selector :checkbox should stay a library level piece of sugar because [type='checkbox'] already exists.

Adding such sugar to the selectors4 API would just bloat it to no end.

gnarf commented Oct 27, 2011

I personally think 80% of the sugar we added is useless and crufty. (:checkbox/:radio/:submit/etc) I categorized all of the jQuery extensions to the selector language on the api site a while back so you can see the sugary selectors yourself: http://api.jquery.com/category/selectors/jquery-selector-extensions/

I think that :visible and :hidden might have uses in selectors for JavaScript land, although they make very little sense inside a CSS stylesheet. The only other candidates IMO are :input as a shortcut for any form element input,button,textarea,select and :header as a shortcut for all the h1,h2,h3 tags. And the attribute not equal selector seems like it has uses as well

ajpiano commented Oct 27, 2011

jQuery's positional selectors (:first, :last, :eq(n)) cause a fair amount of trouble and bugs (which we've now categorically wonfixed, but are also fairly popular with users. I'm not sure if introducting such a hairy concept to QSA itself is particularly desriable, however.


Agree with @gnarf here; most of our custom selectors can (and should) be replaced with standard ones using a few more keystrokes. Since :header conflicts name-wise with <header> I wouldn't suggest we do that. It might be good to have a pseudo-selector like :input that selected all potentially serializable form elements, although that should be in form.elements as well.

I just saw a ticket yesterday with good use cases for :visible to zebra-stripe a table:


Using something like that in a style sheet would make sense I think.


:input in css doesnt seem all that logical as how often are you styling all inputs the same way?
Fonts? Floats? Display?

gnarf commented Nov 30, 2011

I'm not so sure it would be useful in styling, but it makes sense as a selector for DOM queries most of the time - if it were included it might save someone some typing.


I assume the current selectors4 already covers this. Please re-open if necessary.

@leobalter leobalter closed this Apr 22, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment