Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Available selectors don’t meet developer needs #3

Open
paulirish opened this Issue · 6 comments

6 participants

@paulirish
Owner

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

References

http://dev.w3.org/csswg/selectors4/

@Raynos

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
Owner

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

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.

@dmethvin
Owner

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:

http://bugs.jquery.com/ticket/10591#comment:2

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

@eddiemonge

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

@gnarf
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.