Skip to content

Markdown rendering of description can be surprisingΒ #225

Closed

Description

@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.

Activity

  1. luke-hill commented on Jun 23, 2022

    @luke-hill
    Contributor

    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: 
    
  2. davidjgoss commented on Jun 23, 2022

    @davidjgoss
    Member

    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.

  3. mattwynne commented on Jun 23, 2022

    @mattwynne
    MemberAuthor

    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?

  4. davidjgoss commented on Jun 23, 2022

    @davidjgoss
    Member

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

    This seems to be the loophole?

  5. mattwynne commented on Jun 23, 2022

    @mattwynne
    MemberAuthor

    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?

  6. mattwynne commented on Jun 30, 2022

    @mattwynne
    MemberAuthor

    πŸŽ‰ thanks @davidjgoss!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions