this is my first bug report, so please bear with me if my post doesn't live up to the standards of the typical bug reports found here.
According to the specification, white-space: pre-wrap should not collapse sequences of white space at the end of the line in a textarea, however webkit based browsers do not conform to this. On the contrary all other rendering engines ( gecko, presto, trident ) have the same behaviour: they break sequences of whitespaces and move the broken part to the next line.
gecko, presto, trident (ff, opera, ie):
* white-space: pre-wrap; Breaks sequences of whitespaces at the end of the line ( correct behaviour ) and moves too-long-to-fit words to the next line ( correct behaviour )
webkit ( chrome, safari ):
* white-space: pre-wrap; Collapses sequences of whitespaces at the end of the line ( wrong behaviour ) and moves too-long-to-fit words to the next line ( correct behaviour )
If you visit this jsfiddle: http://jsfiddle.net/LXUEe/2/ and you place the cursor in the textarea and start entering consecutive spaces, you will see that the cursor will just get "stucked" at the end of the box ( whitespace collapsing ). No other browser ( rendering engine ) other than chrome/safari does this. The correct ( desired ) behaviour for whitespaces, should be the one it would have if you set white-space: pre; and I would happily use that if chrome didn't break words ( maybe another bug? -- unlike every other browser ) at the end of the line, instead of moving them to the next line.
So due to this bug, it's not possible to have in webkit a textarea which simultaneously doesn't break too-long-to-fit words AND doesn't collapse sequences of white-spaces.
Ryosuke, can you triage? I think you're a knowledgeable textarea person, right?
CCing some more text editing people. I'm not really sure who knows about this stuff. Also now that Blink has happened I don't know if Google people are paying attention to webkit bugs, but here's hoping.
This is intentionally done in order to match standard word processing behavior (e.g. TextEdit, MS Word, etc. all do this). That said, I agree that the web doesn't need or want this behavior. This is likely something we'll change in Blink once we find the time.