John Resig has published a long and very interesting article about CSS 3 Selectors. Being the original author/editor of that spec, I feel I have to answer to his points.

First John sees these selectors from an HTML point of view. I remind the reader that Selectors are not designed specifically for HTML. We had XML in mind when I edited the spec.

Second, when he says "What's fascinating is that no one has ever, ever, requested that these features be added back in. They have virtually zero real-world use and applicability", I think John should think twice before being harsh with the CSS Working Group and the XSL Working Group. Most of these selectors were added to the spec - or taken from the an old XSL draft - after we provided uses cases. Furthermore, most of these selectors are not implemented by IE and not yet by Firefox. Why the hell do you want people to care about them ? There's not a single book about them because the spec is not a REC yet ! Let me give another very concrete example : when Håkon Lie proposed :target, it was only for navigation ; nobody ever expected what I did with it : tabs with a demo!!!

So we have here selectors that are not implemented yet or not interoperably and Web designers don't use them. How surprising !!! In CSS, we have some features here to serve some typographic local constraints, because we saw a menu in a restaurant nicely designed and we needed a new feature to be able to make it in CSS. Serves a very little community of users. That community will NEVER show up in any stat. Is that a reason to drop the feature ? You don't see a wide community of users for a given selector ? Is that a reason to drop it ? CERTAINLY NOT.

On the selectors themselves, here are my comments:

  • E:root - very very useful if you consider scoped stylesheets
  • E:empty - very useful for inline editors so they can present differently an element if it's empty
  • E:lang(fr) - yeah, there are only a few multilingual blogs around... I have plenty of them in my RSS agregator, and my own blog is multilingual tagged with lang. Want to see only french content ? *:not(:lang(fr)) { display: none }
  • E:nth-of-type(n) - very sueful to present financial tabular data where odd rows are grey and even rows white for instance
  • E:nth-last-child(n) - similar to the previous one but when you want the last row to be always grey
  • E:nth-last-of-type(n) - idem
  • E:first-of-type - some online newspapers show the first paragraph of their prose in a bigger font, that's #content > p:first-of-type { font-size: larger }
  • E:last-of-type - wonderful to put generated content after the last paragraph of a prose for instance
  • E:only-of-type - I have at least one test case : to change the rendering of a list item if it's alone in its list parent
  • E:only-child - when you're inline-editing : dl > dd:only-child { /* special rules */ }
  • E ~ F - we used a ~ because the combinators we don't have an unlimited set of available combinators. It's only in one direction LIKE EVERYTHING in CSS selectors. You cannot select an element based on its children, you cannot select an element based on its successors
  • E + F - I agree this one is less interesting than the previous one but I use it from time to time, in particular when styling XUL or tag soup coming from an uncontrolled source.
  • E[foo~="bar"] - .class does NOT EXIST for XML because the class attribute is not a cross-dialect generic attribute. So we need this one to make class happen in XML.
  • E[hreflang|="en"] - Oh you english speaker, you should leave a little bit the en-GB and en-US-centric web :-) I know a lot of blogs and sites using this to show the user the target of the link is not in the originating site's language...
About selectors' speed, you seem to forget BROWSERS are not the only environments implementing selectors. Prince for instance has a BATCH processor to print books from HTML and CSS. Speed still matters, but less than in a browser. Again, you made a very common mistake in our world, you read this spec with an HTML-only browser-only eye.