Reason to Use Them

Before getting into the “how" of using CSS selector libraries, it’s probably best to get the “why" (and “why not") out of the way first. It goes without saying that these libraries add a layer of complexity to applications that use them, introducing another potential point of failure. They implement expression parsers in order to take CSS selector express ons as their input and translate them into equivalent userland operations, which can have an impact on performance.

Those points aside, they do offer a syntax that is considered by some to be more intuitive. Most developers these days know at least some CSS and probably have a little experience with a JavaScript library that uses CSS selectors for node selection on the client side, such as jQuery Thus, knowledge of that particular area is transferable to the server side when libraries based around it are used.

To sum this up, if you’re particularly concerned about performance or simplicity of the application with regard to the number of components on which it is dependent, it’s probably best to stick with something like XPath. Otherwise, CSS selector libraries are worthy of consideration for making use of a common existing skillset.

Even if your decision is to stick with XPath, keep reading. This chapter will also show some XPath equivalents for each set of explained CSS selectors, which may help to further your understanding of XPath. Note that these comparions are not necessarily comprehensive and there may be multiple ways to express the same thing in any given case.

jQuery Examples

The documentation for the jQuery library itself actually has excellent visual client-side examples of selectors. If you find you aren’t certain that you understand any of the descriptions of CSS selectors that follow, the jQuery demos and source code will likely prove to be helpful supplements. You can find them at http://api.jquery.com/category/selectors/.