Trailing non-breaking space not caught by trailing whitespace detection

[oliverguenther]

I'm not sure If I have overlooked an option or a discussion where this was talked about in the past, but whenever an inline style has a trailing (or leading) nbsp whitespace, the resulting commonmark is invalid since its no longer a flanking run.

For example, this HTML

  <strong>bold&nbsp;</strong>

results in the following string

**bold **

http://jsfiddle.net/29hqet7s/6/

This appears to be related to both #222 and #102.

I'm wondering what the expected result should be. I would expect it to either output the entity or strip it. On the latter issue you mentioned this exact issue regarding trailing whitespace, so I would assume this is the expected behavior? I would like to send a PR for either option (possibly behind a flag?)

[martincizek]

I'm wondering what the expected result should be.

The current Turndown's approach for ASCII whitespace is to move the space out of the inline element. I.e. <strong>foo </strong>bar becomes **foo** bar.

The best thing we can do for non-ASCII whitespace is actually the same, it just should not be merged with other whitespace. So the best result we can think of is probably

<strong>foo&nbsp;</strong> bar-> **foo**\u00A0 bar.

We have done a thorough analysis on the topic: https://github.com/orchitech/turndown/wiki/Whitespace

And a PR will come soon. :)