Markdown rendering of description can be surprising

[mattwynne]

🤔 What's the problem you're trying to solve?

See this comment

People are surprised when deliberate newlines disappear when their features are rendered.

✨ What's your proposed solution?

I suggest adding a title element somewhere that contains the original raw text from the description field so there's a bit more transparency about what's happening.

⛏ Have you considered any alternatives or workarounds?

We could also add some kind of option to toggle markdown rendering (and if markdown's disabled, just use a fixed-width font for the description)

📚 Any additional context?

https://cucumber.io/blog/bdd/user-stories-and-bdd-features-are-not-stories/ 😉

---

This text was originally generated from a template, then edited by hand. You can modify the template here.

[luke-hill]

Looking at the raw source which is present inside the html, the original quantity of newlines is present, but it's one huge data-chunk, as opposed to split up ones. The full raw text from the .feature file is present in this stream.

A partial example is

{"line":53}}}},
{"source":{"uri":"features/foo/bar/baz.feature","data":"Feature: Forgot Password\n\n  As an existing customer\n  I want to be able to reset my password if I have forgotten it\n  So that I can continue to use the thing\n\n  This requires a foobarbaz\n  They then must subsequently do a barbazbay\n\n  Scenario: 

[davidjgoss]

We could also add some kind of option to toggle markdown rendering

FWIW, I think we are slowly rolling towards having some kind of options mechanism for the HTML formatter. There's stuff like #181 and also theming - nothing has yet been compelling enough on its own, but maybe collectively it's worth a look.

(and if markdown's disabled, just use a fixed-width font for the description)

Minor point, but rather than a monospace font I think we'd just use the regular font and white-space: pre-wrap in order to preserve the original spacing.

[mattwynne]

Interestingly, these comment blocks in Github (which I assume use GFM) do preserve newlines:

First line
Second line

Which comes out as:

<p>First line<br>Second line</p>

That doesn't match my reading of the spec. I wonder what's going on?

[davidjgoss]

A renderer may also provide an option to render soft line breaks as hard line breaks.

This seems to be the loophole?

[mattwynne]

Ha! So maybe we can just turn that on in order rendering component?

Looks like we might need https://github.com/remarkjs/remark-breaks maybe?

[mattwynne]

🎉 thanks @davidjgoss!