Fair enough.

function( text ) {
     return ! text ? "" : text.toString().trim() ;
 } :
// Otherwise use our own trimming functionality

-- DBJ

I would really prefer to not throw an exception - we generally try to be forgiving of user input (trying to handle null/undefined gracefully, for example) and I'd like to continue that trend.

I can't believe how much time we have spent discussing string trim .... And ... I still can't stop ?
What strikes me above is that if String.prototype.trim is available then using the native trim boils down .. to erm, actually using it :

  function( text ) {
     return text.trim() ;
  } :
  // Otherwise use our own trimming functionality

Above will also behave properly, and in the case of text , not being a string, the above will/should throw TypeError.
--DBJ

I hope it is not patronising if I offer this : http://gist.github.com/329172

Thanks : DBJ

Results from http://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...