The use of CSS selectors for DOM queries

[jkd]

I must admit to not understanding the trend in using CSS to do DOM. Every major JS framework includes a selector engine, and browsers are implementing querySelector and querySelectorAll left and right. Now, I understand that utilizing the DOM Core API can be tedious, but using Array extras and either converting collections to arrays or modifying collections' prototypes can reduce the overhead in code-size.

So again I ask, why CSS selectors? XPath is far more powerful and capable of more finely selecting elements both upwards and downwards the tree, and there are JS-based XPath engines as well as browser-native methods (document.evaluate, for example). For the types of traversals CSS is capable of describing, the equivalent XPath is at least as simple. But even if one doesn't buy the at-least-as-simple argument, then why are frameworks using CSS instead of some simpler (and faster!) API? Using functional programming, it's easy to chain together function calls that can do the same as CSS selectors (and faster, since there is no compilation or parsing phase).

The fact that they don't must imply some inherent advantage to using CSS over simpler, faster methods, or about-as-simple, more powerful methods. I can think of two explanations:

1. Selector re-use; it is possible to directly reuse the selectors used to style to apply a behavior to the same elements.

2. Familiarity with CSS in the developer population.

However, I believe both explanations are insufficient; for #1 to be useful, one essentially needs to copy-and-paste selectors from CSS into the JS. But whenever copy-and-paste is used to maintain code-concurrency, inevitably the source diverges and bugs are introduced. It would be possible to scan through the list of CSS rules using the DOM until the desired selector is found, then use the text of the selector in the function call, but we still need to know what selector we are looking for, which doesn't solve the problem (at least, without abusing class attributes or rel attributes).

As for #2, I don't think that makes any sense. Once they have their desired list of DOM nodes, the developers will be attaching event listeners, reasoning out complicated DOM interactions, etc -- if they can't figure out how to query the DOM without CSS selectors, then they probably can't do what they want anyway. Furthermore, if they do know how to do what they want (or they've at least learned the robust API of whatever framework they are using), then they are capable of learning whatever simple query language you throw at them.

So again, I wonder the reasons for reusing the headaches of CSS to do DOM querying. Any thoughts?

[rnd me]

interesting topic, thanks for posting.

css has one huge thing going for it: momentum.

there are tons of tutorials, cheatsheets, etc that teach how to use them.

if you have to learn a query method, why not use the one you need to know to make webpages anyways? IE7's improvements reflected the fact that there are far more people who can crank out a page in dreamweaver than hand-code dom queries.
MS thought it was more important to target designers than coders, based on the numbers.

There is nothing to stop anyone from using whatever scheme imaginable to query, css is just the most famous query system.
We like using filter functions, but i would guess that half of the people writing javascript don't know what [].filter even does...

I agree that custom code is more flexible and perhaps faster.
I think that xpath leaves a lot to be desired in terms of compatibility, as do native object upgrades like array/collection extras.


having coded xslt, i know it's painfull.
if i had to do it again, i would rather use jquery on json using css-like expressions to build an equivalent page.
I think a lot of people must feel the same way...

[jkd]

I think that xpath leaves a lot to be desired in terms of compatibility, as do native object upgrades like array/collection extras.

having coded xslt, i know it's painfull.
if i had to do it again, i would rather use jquery on json using css-like expressions to build an equivalent page.
I think a lot of people must feel the same way...

A note on XPath's compatibility: Firefox, Opera, and Safari all support document.evaluate. That just leaves IE, and there do exist JS-based XPath engines. (This implies that until recently, XPath-querying had better support than CSS-querying within browsers!)

It's also important not to conflate XPath with XSLT -- they exist separately from one another, and XSLT simply utilizes XPath to match nodes. (I personally love XSLT, but that is only after a strong background in functional programming.)

I think you were right about momentum, however. As I noted, evaluate() had better cross-browser support than querySelector() until very recently, but obviously it did not take off. The abundance of CSS tutorials geared towards designers versus the paucity of XPath tutorials for designers probably had something do with that. Again though, if a developer is capable of writing these complex interactions, I don't see why they would settle for something as limiting as CSS.

[rnd me]

Again though, if a developer is capable of writing these complex interactions, I don't see why they would settle for something as limiting as CSS.

if by developer you mean programmer, they are likely settling to be using javascript in the first place. i bet very few programmers have been excited about javascript the language. just a few year ago, most programmers scoffed at javascript.

I am sure we could have much better web apps if something like silverlight had taken off 10-15 years ago. programmers could code in whatever language they were used to, and everything would work for everyone.

the reason people want to write programs in javascript is that a billion people can use your app tommorow. no installing, no dlls or rebooting, just use it.

That's a pretty big offer, and increasingly worth the sacrifices/compromises compared to more powerful programming possibilities.

in a similar fashion, i think css queries might be a bit compromise. kind of like the backing off of prototype stomping the last few years. Getting libraries to play nice together require some sacrifices on the lib developer. community safety -vs- individual rights.

everyone sharing $$() instead of building thier own collection protos cuts down on potential conflicts. reducing conflict has been a top priority for recent library development. at first it was all about power, now it's all about sharing.