41–50 of 51 posts
It's a serious question. What benefit is there to doing this?
The only thing that came to mind is now you have the dom node so you can bind events to it. But you're not going to be doing that everywhere. So why make things more complicated?
Your API will explode violently in IE 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...
Object.prototype.toString ( ) When the toString method is called, the following steps are taken:
1. If the this value is undefined, return "[object Undefined]".
2. If the this value is null, return "[object Null]".
3. Let O be the result of calling ToObject passing the this value as the argument.
4. Let class be the value of the [[Class]] internal property of O.
5. Return the String value that is the result of concatenating the three Strings "[object ", class, and "]".
Just for fun, here's my version from 2006: http://mg.to/2006/02/27/easy-dom-creation-for-jquery-and-pro... It's based on Bob Ippolito's version from 2005. :-) The comments on the post have a few other interesting implementations that others contributed. At the time I got pretty excited about this idea, but I abandoned it after a while for performance reasons. I was building large DOM structures and it was really slow…
JavaScript has come a long way, even from 2006, yet most developers still have the mindset that this sort of thing can't perform well. What we're left with are solutions that are more complex, and perform similarly for most applications.
It also allows you to generate HTML strings from the same code and create templates, with template inheritance, using the same sort of syntax.
Earlier quoted context omitted.
Sort of, but there are some tags you probably don't want to pollute your own top-level namespace with, like a, b, i, object, p, q, and s. There's at least one tag (var) which is not allowed as an identifier on its own.
You could use with(){} in js so you don't have to pollute your global namespace and still have pretty code.
Earlier quoted context omitted.
I think 'a' and 'p' are the only ones among those you'd actually want. I could probably live with with those limitations.
Now that I think about it, that might break a few sortFunction(a,b) {//do stuff with a and b} type functions of mine...
What's more of a problem is if you have something like this: https://gist.github.com/2499913
The problem is that the "var p" in the for loop will be hoisted to the top of the scope, and so when you call p() in the first line, it will actually be undefined.
Your API will explode violently in IE 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...
The "Object.prototype.toString.call" solution is guaranteed to work according to ECMA-262, and will only return true for a real Array instance (not something masquerading as an Array): Object.prototype.toString ( ) When the toString method is called, the following steps are taken: 1. If the this value is undefined, return "[object Undefined]". 2. If the this value is null, return "[object Null]". 3. Let O be the resu…
This is because there is no defined standard for `toString` results of host objects.
Thanks!