Results from https://jsbin.com/ehoje/12
Opera

    userAgent :Opera/9.80 (Windows NT 6.1; U; en) Presto/2.6.22 Version/10.50
   String.trim() → undefined
   String.protoype.trim() → function trim() { [native code] }

Safari

          userAgent :Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/531.21.8 (KHTML, like Gecko) Version/4.0.4 Safari/531.21.10
         String.trim() → undefined
         String.protoype.trim() → undefined

Chrome

        userAgent :Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.2 Safari/533.2
       String.trim() → undefined
       String.protoype.trim() → function trim() { [native code] }

FireFox

      userAgent :Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6
     String.trim() → function trim() { [native code] }
     String.protoype.trim() → function trim() { [native code] }

With IE I have not bothered ...

I really think we should not rely on String.trim() , being universaly avaialble

Thanks: DBJ

Sorry I was to busy for a comprehensive comment.

" .... Also, there is no left/right trim in jQuery - only the one trim....

inside jQuery.extend we have this comment :

          // Trim whitespace, otherwise indexOf won't work as expected

And this declaration :

        rleadingWhitespace = /^\s+/,

Which now obviously should be removed and (tne new and correct)

         trimLeft 

Should be used, I think ?

Second. String.prototype.trim ---- v.s.--- String.trim

               15.5.4.20 String.prototype.trim ( )

The above is the only legal ES5 , trim() . There is no String.trim() in ES5. This is why I would rather not use it ....

Thanks: DBJ

@DBJDBJ: I'm not sure what you mean regarding String.prototype.trim - we don't use it, we're only using the native String.trim method, so it's best for us to check to see if that method exists. Also, there is no left/right trim in jQuery - only the one trim.

Also , I seem to remember there is a trim left and/or trim right somewhere in jQuery which now can be changed to use trimLeft ot trimRight , regular expressions ?

Thanks: Dusan

@john : thanks for commendation ;o)

one note ? to avoid all browsers ES5 transitional period pains, I would rather test for trim() existence like so :

 var native_trim = "function" === typeof "".trim ;

Some browsers support and implement String.prototype.trim, but not String.trim, I think ?

Thanks: DBJ

@rkatic: Good point, just landed that change: 0a307b3

nvm, this fixes "etc"...was hard to see context

in the templating proposal you noted "This appears to be a bug in the appendTo, etc. implementation..."

etc?

Then why no just:

jQuery( insert[i] )[ original ]( elems );

Comments are verboten.

On a serious note, it's a popular idea that code should be clear - that if a piece of code needs comments to explain what it does, then that piece of code should be rewritten no longer to need comments.

Appropriate optimizations are exceptions to this rule, as are such things as high-level descriptions of algorithms and data structures, high-level descriptions of design and architecture, examples of how to invoke the code, key assumptions and contexts, etc.

Why not use +new Date() and then include a comment. You know, one of those new-fangled thingamawhatsits often included in source code just like this that explains to the uneducated developer what that particular bit of magic does?

*erm "use strict";, humor fail :D

Hehe, I hear @kangax is getting a tramp stamp that reads "strict";

@jdalton: To someone that reads specifications for fun, of course there's "Nothing magical about it." - but it's undeniable that it's much more obtuse than just doing a straight (new Date()).getTime(); or (new Date()).valueOf();.

Nothing magical about it. ECMA 5th Ed. Page 169, Section 15.9.3.1 [[PrimitiveValue]] makes it pretty clear. (new Date).valueOf(); would also do :P

Fair point. I'm surprised closure compiler doesn't switch new Date().getTime() for +new Date...

@James: Nothing in particular (in that it works) but I've balked against it in the past because it's particularly "magical" and not always obvious what it's doing to someone who may be reading the source - whereas (new Date()).getTime() is very explicit and very obvious as to what the result is.

In reference to 806, what's wrong with +new Date()?

            isNode = elem.nodeType;

Is this robust enough ? In any case API doc should warn against { "nodeType" : "whatever" }
Ultimately there should be a method :

           jQuery.isNode = function ( object ) {
                  return "number" === typeof object.nodeType && object.nodeType > 0 && object.nodeType < 13 ;
           }

Or some more elegant implementation ... But I think we can't leave this as it is ?

DBJ

Not visible in this diff, the events and handlers are already declared as variables at the beginning of jQuery.event.handle.