Since jQuery.trim uses a polyfill for String.trim it would be nice if it could match the full spec.
If this is used just internally for jQuery as @dmethvin said there's no reason to expose as an utility, right?

Let's not go overboard here. jQuery.trim is a perfectly useful public utility that happens to utilize native trim where it can. We don't need to drop it just because it doesn't trim all random unicode space characters in every browser. Let's be honest and make up statistics. 99.9% of users don't care about these characters. They care about " ".

Since jQuery.trim uses a polyfill for String.trim

The documentation says nothing about this.

If this is used just internally for jQuery as @dmethvin said

I said " jQuery's internal utility methods are often intended for specific situations inside the library where the complex edge cases don't matter." It wasn't our intention to expose a polyfill of String.prototype.trim under the name of $.trim and be tied to a spec that requres things we don't need internally.

there's no reason to expose as an utility, right?

The only reason to continue to expose it is because the cow has left the barn, the cat is out of the bag, the condor has taken flight. We definitely would not have exposed it if we understood the level of bikeshedding it would induce.

The documentation says nothing about this.
99.9% of users don't care about these characters

Sure, that was just a personal thought based in the source and in the fact that is a public api...

Sorry to have brought the bikeshed back to the forefront. I obviously can't speak for the entire community but if this were moved out of core and into a plugin that wouldn't seem inappropriate.

@wwalser Handling BOM seems like a reasonable endeavor to me. It's the idea of a full-fledged trim polyfill for the sake of it that's a bit overkill.

So thanks for the PR ;)

I updated the tests and landed this so it would get into 1.8.1, thanks!

Breaks in Safari 5.0. So now we not only need to detect a missing String.prototype.trim, but we need to detect a broken String.prototype.trim. I fear it will take some bytes to do this. http://swarm.jquery.org/result/165379

Wait, are you saying that Safari 5.0 recognizes BOM as whitespace in the regex engine but doesn't trim it?

Seems like it... makes you wonder about this BOM/NBSP feature inference now, doesn't it? :P

Maybe. The new inference that if \s recognizes \xA0 it will also recognize \uFEFF may have failed or the existing inference that regexs \s recognition is the same as what's trimmed by prototype.trim might have failed. We can't actually tell from this test result.

It's not actually any of the inferences that are hurting us here. As Dave pointed out it's the existence of a String.prototype.trim which is broken that's hurting us.

    trim: core_trim ?
        function( text ) {
            return text == null ?
                "" :
                core_trim.call( text );
        } :

        // Otherwise use our own trimming functionality
        function( text ) {
            return text == null ?
                "" :
                text.toString().replace( rtrim, "" );
        },

core_trim is true. rtrim, the result of said inference is never used. String.prototype.trim exists and is not implemented to spec. Unfortunate, unsurprising, and true.

This would require additional bytes, scrap it.

Thanks guys! sorry it didn't work out.

@wwalser the remark shouldn't be taken literally. What I'm saying is that, when you cannot even trust standard methods to be implemented correctly, you're probably better off not making any inference in your code, period.

It's not about the browsers that jQuery supports today, it's about the ones it will have to support tomorrow (FF & Chrome are very aggressive and very breaking in that department). Everytime we release a new version, we hope for it to be the latest in it's 1.x branch. If such is the case, then some sites will have this version for a looooong time (1.4.4 anyone?). Now, comes along a browser that does break a single assumption...

Feature detection should be as bullet proof as humanly possible (as in testing for the exact blank the workaround is supposed to fill), feature inference should be avoided at all cost, since it doesn't test for the blank itself and, thus, is just browser sniffing in disguise, even if it actually sniffs a large range of browsers: "this is true, and in every browser I know I can deduce this totally unrelated thing is true too so it will always be true no matter what".

I find it sad that we could actually feature detect here but just refuse to do so because "we know of no browser that would break the assumption" or "it saves 4 bytes". That doesn't sit well with me regarding how jQuery is supposed to endure a little past the few browser versions it supports right this instant.

And I know we cannot safeguard against all future bugs, but I sure hope we can properly handle the ones we fix today so that the code is adapted to variations on the same theme.

I hope I made my reasoning a little clearer.

Landed gh-902 instead. @wwalser thanks for your work here, I hope it's a little clearer what we go through for even the simplest changes. 😓 When we're supporting so many (broken) browsers, nothing is simple! We are hoping to have automatic Testswarm runs for pull requests soon, which would have identified the problem with Safari 5.0 before the code landed in master.

Nice, thanks for the update.