The DOM is not CSS. Please realize this. Your monstrosity of a query illustrates a continued ignorance of the DOM.
"event normalization" is another "nice-to-have" that isn't necessary. DOM 0 event handlers (e.g. `node.onclick`) have worked for decades. Each node may only be allowed one handler, but there's more than enough nodes to get the job done. Of course, event delegation can be used to handle more than one event, so this becomes moot.
I can guarantee you that the frivolous "productivity" gains from chaining Frankenstein queries like yours are mitigated by massive speed losses from parsing.
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?
> 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?
> 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.
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.
> 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).
IE6 is below 5% market share. But if you absolutely have to support IE6, then yeah, use JQuery.
There are still some differences in modern browsers but those can mostly be repaired with polyfills.
Oh, and while I would not recommend doing your chaining operation (chaining just makes it harder to debug), I can write the same thing in one line of JavaScript:
Yeah sorry that one liner is pretty ugly. Also I don't see the issues with chaining and debugging. Chrome has a v.good debugger. And to top it off querySelectorAll requires ie8+.
Why not just use a extremely well tested library that automatically gives you full browser support? All for the equivalent price of one very small jpeg file.
hehe just came back to check my comment history... dude u really created what 3.. 4? different accounts to reply to my messages?? Lol i really got under your skin. you are familiar with this right?
You had said that it was 10 - 20 lines of code. The reason I posted my original comment is that many jquery abusers don't know about alternatives.
Why not just use a extremely well tested library that automatically gives you full browser support?
You have to justify why you use something additive, not why not to use it.
All for the equivalent price of one very small script file.
Not quite sure why the load time of the script file gets so much attention. It is hardly to real expense of jquery. Many, many, many jquery-crutch sites are horrendously inefficient because they think that the magic of chaining and the robust selector language comes for free. It does not -- it comes at an often significant expense.
c'mon you know i meant that 10-20 lines are for an ie6+ solution.
You have to justify why you use something additive, not why not to use it.
If your decision not to use jQuery (or another lib that makes your life easier) is because of performance then you're optimising much too early.
Personally I optimise for developer time first and raw performance much further down the line.
And dom querying is not usually the bottleneck in most sloppy sites... its way too many event listeners. And jQuery comes to the rescue once again with extremely easy (to read and write) event delegation.
Sorry I don't mean to offend you or anything... but if you're rejecting jQuery or extjs or zepto etc. on the basis of performance then you're probably doing it wrong. Keystrokes count. Libraries allow you to focus less on plumbing. That's the whole point.
> you're kidding me right? Obviously you filter your queries to the closest node.
Smart aleck 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. Some scripted query engines (e.g. YUI) ignore the disagreement, favoring wrong answers fast over right ones slower.
When the libraries 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.
> Having css3 query support in legacy browsers is awesome.
Except that you don't have anything close to that (assuming you are using one of the "popular" libraries). And, even if you did, would you really want to send that crap to an iPhone?
Only way to do it efficiently is to load the library inside conditional comments and use QSA for everything else. That is assuming you can find a query engine that actually works as expected in IE 6/7.
>> massive speed losses from parsing
> Nobody is searching the entire dom for matching nodes.
Parsing selectors is parsing selectors, regardless of how they will be used. One element or the entire DOM; it doesn't make a bit of difference.
> 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.
Oh, but wait, jQuery tangles up queries and event delegation with its "Live" feature. So you are screwed either way. :(
And those "Frankenstein queries" are the exact opposite of self-documenting code (something most jQuery proponents/marketers get backwards).
Oh and try querying for something like this in ie6.
'.class + .other_class > .yet_another_class'
Having css3 query support in legacy browsers is awesome.
Not to mention productivity gains from method chaining and batch assignment such as
$('.somehting').find('*').css({'font-weight': 'bold'});
Do you really want to type the 10-20 lines of JS that are required to make that happen? I don't.