[XLcommerce]

you're kidding me right? Obviously you filter your queries to the closest node. Are you testing your code on ie6 running on a 486? Even a 486 could parse out a handful of nodes from a dom sub tree in max double digit milliseconds.

Those 'Frankenstein' queries are ridiculously easy to read and to type.

'massive speed losses from parsing'

Nobody is searching the entire dom for matching nodes.

The single biggest performance killer... far more important than tree traversal is event overhead. As long as you think long and hard before applying a new event handler (and use delegation whenever possible) you'll be fine even with those 'Frankenstein' queries hehe :P

The DOM is not CSS.

What does that even mean in this context?? How does it further your point?

illustrates a continued ignorance of the DOM

enlighten us then...

[mkmcdonald]

> Are you testing your code on ie6 running on a 486?

I test all the way back to IE 5.5. Try browsing a site with a heavy jQuery dependency in IE 5.5 (StackOverflow is a nice example). Those sites tend to implode.

> Those 'Frankenstein' queries are ridiculously easy to read and to type.

You sure about that?

A: `$(someForm).find("input[name=whatever]")`;

B: `someForm.elements.whatever`;

B is quicker to execute, type, and read.

Try running some speed tests on `find`. You'll notice it's pretty inefficient.

> Nobody is searching the entire dom for matching nodes.

I should start counting the number of times I encounter `$(".stupid")` reading source code. The count would probably be in the thousands.

> What does that even mean in this context?? How does it further your point?

Using "CSS selectors" to traverse a tree of nodes is utterly stupid. That's what recursion/tree traversal algorithms are for. What's nice is tree traversal is rarely necessary. Selecting via `id` or `name` (through an `HTMLCollection`) is quick and easy.

> enlighten us then...

I've posted 3 comments now on this topic. Shall I link various DOM specs?

[XLcommerce]

Using "CSS selectors" to traverse a tree of nodes is utterly stupid.

Clearly your opinions differ from the majority of the web community.

Why do you think we now have document.querySelectorAll?

Have a look at the mdn article: https://developer.mozilla.org/en/DOM/Document.querySelectorA...

example given on that page: var matches = document.querySelectorAll("div.note, div.alert");

also :

http://www.w3.org/TR/selectors-api/

Makes perfect sense.

That's what recursion/tree traversal algorithms are for

No. That's what highly optimized browser internals are for.

I test all the way back to IE 5.5

Why? ie5.5 is 12 years old.

[mkmcdonald]

> Clearly your opinions differ from the majority of the web community.

> Why do you think we now have document.querySelectorAll?

This is called "argumentum ad populum" (appeal to popularity). The advent of jQuery caused clueless "developers" (along with library authors) to beg for "native" selectors. QS(A) is the result. They were never needed in the first place.

> Why? ie5.5 is 12 years old.

Internet Explorer's Quirks Mode (which still exists in IE 9) is a simulation of IE 5. It's useful for testing against IE's old box model.

[joesixpack2]

Right and you have to test at least one browser that ranks below your expectations, else you wouldn't know if your feature detection/testing was working.

Granted, the typical Web developer will simply announce they don't care about any browsers deemed inferior (or unknown to them) at the time. History has shown that such carelessness leads to sites that are more likely to break in future (unknown to them at the time of development) browsers.

Often the expected outcome for IE 5 is a static page.

[XLcommerce]

caused clueless "developers" (along with library authors) to beg for "native" selectors.

ahh now I get it. you're one of those guys. you're just smarter than everyone else right? good luck with that.

[thissitesucks]

Nooo... you don't.

You are one of those guys that figures anything popular must be smart. Good luck with that. :)

[duko2]

would you please edit/update your non-response to be less useless.

[thissitesucks]

> you're kidding me right? Obviously you filter your queries to the closest node.

You again. Smart-ass doesn't suit you.

Obviously, you can use standard DOM methods (e.g. gEBTN, gEBCN) with the "closest node" as well.

And, assuming you mean an element node, you just bought yourself a world of hurt. jQuery and the like will use the Selectors API (e.g. QSA) when it suits them, and due to their disagreement with the specs, element nodes don't suit them.

When they use their own query code, performance and compatibility go right down the toilet.

In other words, use QSA with the document node, unless you want to relearn how queries work.

> The single biggest performance killer... far more important than tree traversal is event overhead. As long as you think long and hard before applying a new event handler (and use delegation whenever possible) you'll be fine even with those 'Frankenstein' queries hehe :P

Again, event delegation is unrelated to queries. It's silly to assume you can use wasteful queries with impunity as long as you don't attach too many listeners.

And yeah, those "Frankenstein queries" are the exact opposite of self-documenting code (something jQuery proponents get backwards).