4 ms·

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-ha

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.

XLcommerce 15y ago
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 15y ago
  > 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 15y ago
    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.querySelectorAll 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/ 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 15y ago
      > 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.
      - XLcommerce 15y ago
        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.
        duko2 15y ago
        would you please edit/update your non-response to be less useless.
        thissitesucks 15y ago
        Nooo... you don't. You are one of those guys that figures anything popular must be smart. Good luck with that. :)
- thissitesucks 15y ago
  > 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).

XLcommerce 15y ago

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 15y ago
> 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 15y ago
  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.querySelectorAll 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/ 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 15y ago
    > 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.
    - XLcommerce 15y ago
      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.
      - duko2 15y ago
        would you please edit/update your non-response to be less useless.
      - thissitesucks 15y ago
        Nooo... you don't. You are one of those guys that figures anything popular must be smart. Good luck with that. :)
thissitesucks 15y ago
> 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).