Currently if you use Bridgy Publish to POSSE a note from your personal site to your FB, it will do so with all whitespace collapsed.

On the contrary, when Twitter cross-posts to Facebook, it preserves any/all whitespace in the tweet.

When I use Bridgy Publish, I have to go in and manually edit the FB POSSE copy that Bridgy created, and add back in line breaks for example (original: http://tantek.com/2015/232/t1/eat-without-digital-devices and edited FB copy: https://www.facebook.com/tantek.celik/posts/10101843869452633 )

It would be great if Bridgy Publish would preserve whitespace from a note post to the FB post (e.g. especially returns / blank lines).

http://indiewebcamp.com/note#Indieweb_whitespace_thinking

thanks for the detailed request! looks like the root cause is that we use html2text to render whitespace (#291), which expects that only html tags are used to create meaningful whitespace, not newline or space chars due to e.g. CSS white-space: pre* or the recommendation for note post types.

we're now discussing the intricacies of this in practice - how many real world implementations comply, how to handle comparing with other fields, etc.

current proposal is this heuristic: whitespace is meaningful in notes (maybe all h-entries?) if they don't contain <p> or <br> elements.

e.g. my own notes on https://snarfed.org/ pretty much all contain meaningless whitespace, but they also all contain <p>s, so it'd work for me.

a better proposal (imho): interpret whitespace as meaningful in p-content but not in e-content.

current status: trying to understand how to store both HTML and plain text content in ActivityStreams (either 1.0 or 2.0). i've tried to wade through the 2.0 specs a couple times now, and i ended up glazing both times. 😆 😭

http://www.w3.org/TR/activitystreams-vocabulary/#dfn-content-term
http://www.w3.org/TR/activitystreams-core/#naturalLanguageValues

we settled on p-content vs e-content: http://indiewebcamp.com/note#Indieweb_whitespace_thinking

...which is what bridgy publish currently does, so I'm tentatively closing this. feel free to reopen if you disagree!

Thank you for raising:
"a better proposal (imho): interpret whitespace as meaningful in p-content but not in e-content."
really appreciate it - took us a while to get through the details but this ended up working well!