I came across a problem in Internet Explorer (it wasn’t a problem with Firefox) when I was trying to compare two strings. To me, one string looked to have an extra space in the front. No problem, I’ll just call the jQuery trim function. Well, that didn’t work. So I used charCodeAt and found it was ASCII character 160. I looked up char code 160 and saw that it is a “Non-breaking space”. You would think that a “space” character would be trimmed. I looked at the jQuery code that does the trimming and the grep pattern uses \s. So, evidently you can’t use \s to catch the “Non-breaking space” in IE. I wonder why no one else has seen this. I wrote up a test page to illustrate this.
To create the non-breaking space, you can use String.fromCharCode(160) or the Unicode representation “\u00A0″. “ ” doesn’t seem to work when using regular expressions, although it behaves the same when printed.
| Browser | Evaluates character 160 as white-space |
|---|---|
| Firefox 3, 3.5 | Yes |
| Chrome 3.0 | Yes |
| Internet Explorer 7, 8 | No |
| Safari 3.2 | No |
| Opera 9 | Yes |
You saved me hours of debugging in ie. I was using .innerHTML to insert a php page with a table, and i kept getting a runtime error. I spend a good 2 hours debugging only to finally see your post about you having that error when inserting a form within a form. I looked and indeed the DIV displaying the php table had a form around it. Thanks a lot dude!!!
damnit 3 years later and I still run into this bug (with chrome btw)
it looks like a contenteditable uses 160 as a whitespace in chrome (/webkit?)
thanks for your insight