New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] GFM ordered list with inner unordered paragraph list generates two ordered lists. #181

Closed
cirosantilli opened this Issue Apr 29, 2014 · 8 comments

Comments

Projects
None yet
3 participants
@cirosantilli
Collaborator

cirosantilli commented Apr 29, 2014

Input on README.md or issues:

1. 1

    - inner par list

2. 2

Live:

  1. 1
    • inner par list
  2. 2

Expected output:

<ol>
  <li>
    <p>1</p>
    <ul>
      <li>inner par list</li>
    </ul>
  </li>
  <li><p>2</p></li>
</ol>

Actual output:

<ol>
  <li>
    <p>1</p>
    <ul>
      <li>inner par list</li>
    </ul>
  </li>
</ol>
<ol>
  <li><p>2</p></li>
</ol>

Problem: two ordered lists are created.

Why this is bad behavior:

  • according to this new test I added to the Markdown Test Suite, GFM is the only major engine to show such behavior (amongst Recarpet, Kramdown, Pandoc, Multimarkdown, Maked.js, md2html and the original Markdown.pl).

  • other nested structures are fine, it only breaks with nested unordered lists with paragraphs, so it is very surprising behavior.

    Things that only generate one outer ordered list:

    • nested list without paragraphs:

      1. 1
          - list without par
      2. 2
      
    • nested paragraph:

      1. 1
      
          par
      
      2. 2
      
    • nested code block:

      1. 1
      
              code block
      
      2. 2
      
    • nested ordered list:

      1. 1
      
          1. 1
      
      2. 2
      

Tests live: https://github.com/cirosantilli/test/blob/master/ordered-list-with-list-bug.md

@juliangruber

This comment has been minimized.

juliangruber commented Apr 29, 2014

👍

@patcon

This comment has been minimized.

patcon commented Apr 29, 2014

Nice. Did you send an email to support? It's usually encouraged to mention that here, paste the contents, and paste any reply afterward. Just so someone else doesn't redo it :)

@cirosantilli

This comment has been minimized.

Collaborator

cirosantilli commented Apr 29, 2014

I did, and asked them to reply here if possible. If they reply by email only I'll post here. Doing that by default now. =)

@patcon

This comment has been minimized.

patcon commented Apr 29, 2014

Heh 👍

I think they have an internal policy not to interact here fwiw :)

@cirosantilli

This comment has been minimized.

Collaborator

cirosantilli commented Apr 29, 2014

Yes. It's funny. Everyone just copies pastes the reply here, and if they don't GitHub risks getting multiple emails for the same thing. More work for all. Sigh. =)

@cirosantilli

This comment has been minimized.

Collaborator

cirosantilli commented May 2, 2014

https://github.com/petros from GitHub replied:

Thanks for reporting this. We are going to check it out and get back to your as soon as possible.

@cirosantilli

This comment has been minimized.

Collaborator

cirosantilli commented May 19, 2014

Second reply from Petros:

I checked our current tests and I see we are only testing for this version:

1. 1
    - inner part list

2. 2

Notice the missing empty line right after 1. 1? That should produce the expected output. If the empty line version should also work nowadays, we may add it in the future. Thanks for reporting it. I have opened an issue for our team to check it out.

@cirosantilli

This comment has been minimized.

Collaborator

cirosantilli commented Nov 13, 2014

Apparently this was fixed, silently as usual:

  1. 1
    • inner par list
  2. 2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment