kangax, thanks for clarifying which objects are "native" and which are "host". Finally it is obvious that "plain objects" are native, not built-in, objects.

When I said that "plain objects" are DEFINABLE with the literal {...} notation, then I intend that all "plain objects" can be described with a {...} notation.
Created objects with the new Object() notation can be entirely described with the {} notation.

I am conscious that an ideal implementation of isPlainObject is impossible in ES3 (probably even in ES5...), but the current one is a good compromise between accuracy and complexity. I can write several test cases that would make isPlainObject to fail, but that cases would be really unusual in real world. Currently the most slack part of the implementation is probably obj.nodeType || obj.setInterval and maybe I have a more robust (still not ideal) solution for it, but have to make some additional investigations...

And if that's the only goal, why is there a [[Class]] check in current implementation? Does it mean that besides [[Prototype]] == Object.prototype, "plain object" should also have [[Class]] == "Object"?

Well, yes.

It's still hard to explain what "plain object" really is. And the reason I'm bringing this up is that when it's hard to explain what method really does, it usually means that something went wrong and probably needs to be rethought.

Well, maybe someone can explain it better than me. John?
Even if it is not simple to explain, it is still needed to distinguish "option hashes" from other objects.
I AM of idea that it was better to avoid any need of such hard-to-define functionalities, but John probably was of idea that it is worthwhile.

"noop" ? Isn't that: "no operation", abbreviated ? ... what was wrong with some combination of words "empty" and "function" ? I think even: "emptyFunction" would work better.
After all in jQ we have "isArray", "isFunction" ...and other nice descriptive names ;o)

--DBJ

Sorry for getting back so late. I somehow forgot about this "thread". On to the points.

There are native and host objects in ECMAScript. Native objects are supplied independent of host environment. {}, [1,2,3], function foo(){}, Object and RegExp.prototype — are all examples of native objects. Some of native objects are also called built-ins — these are the ones specified in ECMA — Object, Function, Number, parseInt, Math.max, etc. And then there are host objects — those provided by host enviornment (e.g. exposed DOM bindings in browsers are obviously host objects — document, document.getElementById, etc.)

When you say "plain object" is that which is defined with the literal {}, it sounds akward and still unclear to me. {} only denotes how something is created, not what it really is :) new Object(), for example, creates identical type of object, given that Object constructor is not overridden or shadowed. new Object has nothing to do with literal notation, yet it creates an object similar to the one created via {} (i.e. with same internal [[Prototype]] and [[Class]]). If I create my object via new Object() is it not a plain object anymore? It wasn't created with {} after all ;) And what if I created an object with {} and then changed its [[Prototype]] to reference Array.prototype? {}-based definition doesn't seem like a good idea.

We can't detect object's [[Prototype]] in standard ES3 (without __proto__ extension or ES5 Object.getPrototypeOf), so I don't see how it's possible to satisfy o is <plain object> if Object.getPrototypeOf(o) == Object.prototype condition. And if that's the only goal, why is there a [[Class]] check in current implementation? Does it mean that besides [[Prototype]] == Object.prototype, "plain object" should also have [[Class]] == "Object"?

It's still hard to explain what "plain object" really is. And the reason I'm bringing this up is that when it's hard to explain what method really does, it usually means that something went wrong and probably needs to be rethought.

As I commented on jquery-dev I'm leaving it in so that we don't break compatibility with plugins.

Is there any reason to leave jQuery.event.proxy here? I don't see anywhere that uses it now.

Massively better. Hip hip hooray Alex!

Have to say I really appreciate this as one time I needed jQuery as a string and manually escaping all these was a pain.
Don't ask why I needed jQuery as a string.. :D

The MS tool also strips out conditional comments, it seems:

https://ajaxian.com/archives/microsoft-ajax-minifier-vs-yui-compressor

+5; painting it red!

Spelling mistake in event.js: wich should be which

The just do not use the "closure compiler", I guess ?
Is Microsoft Ajax Minifier any good?
https://stephenwalther.com/blog/archive/2009/10/16/using-the-new-microsoft-ajax-minifier.aspx

Weird, the commit message got munged. It should say "Make sure we use jQuery(document) instead of jQuery() in the delegate test.

The Closure compiler strips out comments, so I think the goal was to eliminate conditional comments completely from jQuery so that it is easy to build the compressed version.

kangax, you are right about if (/*@cc_on ! @*/0). My code doesn't even work.

isMaybeLeak/*@cc_on=(@_jscript_version<5.7)@*/ looks much bulletproof.

@NV Or just — if (/*@cc_on ! @*/0). I guess removal of conditional comments is to cater to Closure Compiler (which strips them). if (window.attachEvent && !window.addEventListener) is a decent inference, but might fail when someone defines custom addEventListener on window (as, for example, MSDN demonstrates — https://msdn.microsoft.com/en-us/library/dd229916%28VS.85%29.aspx). The chance of someone following MSDN example is too big, as for my taste, so I'd rather go with something similar to what Garrett does in APE — var isMaybeLeak/*@cc_on=(@_jscript_version<5.7)@*/ (https://github.com/GarrettS/ape-javascript-library/blob/master/src/EventPublisher.js)

Oops, I forgot "@"

if ( window.attachEvent && /*@cc_on 1 @*/ ) {

Just curious, why not

if ( window.attachEvent && /*@cc_on 1 */ ) {

?

@jaubourg : Another thanks for the great follow up tests around the FOUC. I'll be publishing my loader (https://github.com/aheckmann/jQuery.use) over the next few days too as I feel more and more up to it (just coming back from major surgery).

Host objects can have characteristics of native objects such as Object.getPrototypeOf(obj) === Object.prototype but that is not consistent or guaranteed across browsers/environments.

Of course. It is why I used host/native as an condition of the definition.
To be more clearer, we can say that "plain objects" are all "user" objects definable with the literal {...} notation. In fact, first version of the function was named isLiteralObject. Later it was renamed to isPlainObject.

@rkatic Host objects can have characteristics of native objects such as Object.getPrototypeOf(obj) === Object.prototype but that is not consistent or guaranteed across browsers/environments.