Formatting of newlines in gitbook

[spier]

gitbook is the tool that we use to host https://patterns.innersourcecommons.org.

gitbook has (recently) changed the way that newline characters (\n) in our markdown files are rendered.

Previously a single newline character did not generate a line break.
That meant that we could format our pattern files like below to allow for easier line-based commenting when reviewing patterns.

There's a central project that everyone depends on.
What a great candidate for InnerSource!
Unfortunately, the project has grown organically, with various contributions and additions slapped on haphazardly.

Recently gitbook made change in this rendering logic. Now such text in markdown is rendered exactly as shown i.e. each newline in the markdown also leads to a line break in the rendered HTML. This does not look great. See screenshot below.

[dellagustin-sap]

Maybe this was a bug introduced in Gitbook, this seems like a pretty noticeable change, but I could not find a record of it at https://gitbook.com/docs/changelog with a quick inspection.

[dellagustin-sap]

@spier have you tried reaching out to their support?
https://gitbook.com/docs/help-center/further-help/how-do-i-contact-support

[spier]

Yes. Their Support says that nothing was changed in their side. I am reasonably sure that that is not true but I cannot really prove it.

Even proving it would not help me. Rather we have to find a way to make the new rendering logic of gitbook work for us. Or switch to an entirely different solution but they would be a lot more work.

[dellagustin-sap]

Not sure why I'm going through this rabbit hole instead of working on my to-do list, but hey sometimes that happens 😄 .
Their documentation on Markdown is quite meager - https://gitbook.com/docs/creating-content/formatting/markdown, but they do refer to CommonMark, os they are not reinventing the wheel.
CommonMark states (https://spec.commonmark.org/0.31.2/#soft-line-breaks):

A regular line ending (not in a code span or HTML tag) that is not preceded by two or more spaces or a backslash is parsed as a softbreak. (A soft line break may be rendered in HTML either as a line ending or as a space. The result will be the same in browsers. In the examples here, a line ending will be used.)
...
A conforming parser may render a soft line break in HTML either as a line ending or as a space.
A renderer may also provide an option to render soft line breaks as hard line breaks.

I inspected the page:

They are conforming with Common Mark. The browser should be rendering the soft breaks as a spaces.
I did not find why it isn't (maybe some front end / CSS change?).

P.S.: While searching for this I learned the term "Semantic Line Breaks":

• https://glorifiedplumbing.blog/2025/04/21/semantic-line-breaks/
• https://writingslowly.com/2025/01/13/semantic-line-breaks-are-a.html
• https://sembr.org/

[dellagustin-sap]

I stop here, but I think this is the "culprit", the CSS style white-space-collapse set to preserve, coming from the class whitespace-pre-wrap from an upper div.

[spier]

Great debugging @dellagustin-sap . Thank you!

I had approached it from the user perspective first, and compared the current rendering with older version from waybackmachine.

e.g. for the Core Team pattern: current and old (2025-01-24)

I will point gitbook Support to this conversation here. Maybe it helps them to debug the issue on their end.