That may be, but it's poison for host objects. In older IE and Opera builds, `"[object Object]"` comes up often, even for host methods.
This is because there is no defined standard for `toString` results of host objects.
129 karma · joined March 5, 2012
This is because there is no defined standard for `toString` results of host objects.
Using `Object.prototype.toString.call` is also a pretty dirty hack, especially to detect an "array". I think `typeof obj === "object" && obj.length` would suffice, even if certain false positives like string objects leak through.
[0]: http://i.imgur.com/RNBYd.png
[1]: http://msdn.microsoft.com/en-us/library/dd347148(v=VS.85).as...
It displays DOM properties and their current state. That's pretty important to any web developer.
That said, its easy customization and lack of script bloat means that it's more portable (Opera on Mint kills any bloated script).
Be sure not to whine, though, when the abstraction leaks and your code breaks.
I'd hope an amicable, intelligent developer would. Scripts don't always load. Errors happen.
> I understand the myriad justifications for disabling JavaScript, but I don't really care.
How nice of you to pick and choose users that matter. It must be a nice luxury.
To novices and the weak of heart? Sure. I've yet to find a greater source of technical depth regarding JavaScript.
> David Mark's touted his "My Library" as the holy grail of libraries while bashing any others, yet kept it closed source (now abandoned).
It seems that you've turned a blind eye. His code's been available in a multitude of ways (I've used it myself as a learning tool). There's a GitHub repository[0] as well.
> They are as stable as the code using them, just like their server-side counterparts.
The prime difference here is that most browsers do not throw markup errors or halt execution upon a bad tag; they're extremely lenient. Conversely, direct parser access via JavaScript can throw a host of errors and halt execution (as I noted with IE). Fragment builders are hampered because they're either too dynamic for their own good or need to keep a laundry list of valid attributes.
> Would you mind expanding on security?
Apart from the OWASP article I linked earlier, it's more of a statement towards older environments. Browsers today escape input nicely, but that's meaningless for Joe Smith, government bureaucrat on IE 6. I prefer direct node creation patterns via `createElement` et al. for this reason (especially text nodes).
I'd like to think this is because ideas of proper scripting have slowly propagated from goldmines like comp.lang.javascript and into the mainstream. People like David Mark have pulled back the jQuery curtain and shown developers that education really is the solution, not mindless abdication of responsibility.
> It wasn’t so long ago that it was entirely typical for servers to respond to XHRs with a snippet of HTML, but sometime in the last 12 to 18 months, the front-end dev community saw the light and started demanding pure data from the server instead.
Client-side templating was and still is a sham. It requires either an unstable "fragment builder" or `innerHTML` calls. Both are neither stable nor secure (IE is very strict with `innerHTML` in particular). I've dubbed `innerHTML` the "eval" of the DOM as it exposes an external parsing engine to do the developer's dirty work.
Server-side processing is still the best option, particularly because of powerful parsers and the ability to hide domain logic. OWASP has an article[0] that covers XSS and DOM scripting that's fairly interesting.
[0]: https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Che...
I'd guess that these guys have spent a maximum of one month writing JavaScript. It's a giant mess.
All flash, no substance.
Regarding your aside, I'm referring specifically to a generalized approach based on observations and not assumptions. I don't consider something trivial such as `event || window.event` browser-specific; it's a strategy used in accordance with multiple event models. You might be surprised to know that Microsoft created the blueprint for the DOM 3 event model (via attachEvent, etc.). They also were the first to use `innerHTML`, `innerText` and `Element.children`.
I can grasp what you're referring to. Bleeding-edge features are tough to support in large part because of Internet Explorer's slow release cycle.
However, the decision has still been made to jump onto a runaway train. All users should be treated the same. Choose an approach that doesn't pick favorites.
One of the main problems in web development today is the creation of browser-specific code; "IE6" in particular is a scapegoat for poor code. I found that once I studied MSDN and wrote no browser-specific code that IE 8 became elementary to support. IE 7 soon followed. IE 6 & 5.5 were close behind.
For CSS, the key is understanding that every page does not need to look the same. Furthermore, reading MSDN's CSS compatibility grid[1] provides more insight.
For JavaScript, the key is simplification. Using DOM 0 events over fancy DOM 3 events yields big gains. Avoiding selector engines will also yield gains.
I'm getting very tired of incompetent web developers and their browser elitism. Do your homework.
[0]: http://msdn.microsoft.com/en-us/library/ms533050(v=vs.85).as...
[1]: http://msdn.microsoft.com/en-us/library/cc351024(v=vs.85).as...
JavaScript being enabled is not an axiom. The client is a very unstable platform when juxtaposed with the server. A lightweight client facilitates flexibility.
> 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.
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?
"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.
Selectors are completely unnecessary. Class "selectors" are tar pits as they have to search every single node in the current context (usually the entire DOM) and then have to check for a class match amongst a possibility of multiple classes.
Quite simply, if you're using a class "selector", you're doing the user—and yourself—a great disservice. Use `id` hooks where possible and `HTMLCollection`s like `HTMLDocument::forms` and `HTMLFormElement::elements` when `id`s are unnecessary. The speed gains are huge.
Moreover, jQuery completely loses its appeal once the selectors are eschewed. The only legitimate options I see are the `classList` abstractions along with the animation methods. Both are easily replaced with far more modular options (I prefer David Mark's My Library).
In short, please learn about the DOM and how it operates. The browser "weirdness" tends to sort itself out once you realize what's going on.