Skip to content
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

<details> element gets parsed incorrectly when using github flavoured markdown. #5724

Closed
3 tasks done
Pomax opened this issue May 12, 2023 · 4 comments
Closed
3 tasks done

Comments

@Pomax
Copy link

Pomax commented May 12, 2023

  • Searched existing issues to avoid creating duplicates. (this is not a duplicate of the several issues asking for a foldable element: if we ever get one, great, but this is a bug report specifically for <details> getting rendered incorrectly)
  • Confirmed that it can be reproduced in built-in themes without customized css.
  • Searched http://support.typora.io/ (this is an actual bug. It doesn't matter if there's a support article.)

Describe the bug

(Refiled from #5606 which got closed as duplicate of #1939, "Allow empty lines and render Markdown inside HTML tags" which might feel related, but is not this issue, and has been open for five years, so clearly no one is paying attention to it. This issue is purely about the bug in Typora's GHFM parsing, where all the correct elements are already in place, it just does almost the right thing with respect to how it should work based on Github's way of treating the same data, rather than entirely the right thing. It folds content incorrectly)

The <details> element with markdown in it, when using github flavoured markdown as markdown of choice, renders incorrectly.

To Reproduce

Create a new document, switch to source code mode, and fill it with:

This is a test

Preamble

<details>
  <summary>expand</summary>
  
  ```python
  import math
  print(f'pi has value {math.pi}')
  ```
</details>

Lead-out

Then turn off source code mode and note that Typora renders the content incorrectly, showing a clickable summary that expands to "nothing", and the detail's actual content showing after the details element, with a rogue </details> test in grey at the end.

Expected behavior

The markdown inside the details element should get converted just like markdown in any other block context, and the details element should get rendered as an initially clickable summary only, expanding to reveal the converted markdown's content.

Screenshots / Screencasts

Expected result:

Expected expanded result:

Actual result:

Sample Markdown File

See above

Desktop (please complete the following information):

  • OS: windows 10 pro x64, 22h2

Typora Version
1.5.12

Justification for wanting this fixed

This is a paid product, not open source. If your product is based on GHFM, which you claim it is, then this is a bug that should have been fixed five years ago, and should still be fixed now because your product claims to support a format that it only partially supports.

@Pomax
Copy link
Author

Pomax commented May 12, 2023

What it looks like right here on github, the only authority for how github flavoured markdown should behave:


This is a test

Preamble

expand
import math
print(f'pi has value {math.pi}')

Lead-out


As you can see, this is not supposed to render the way Typora's currently rendering it.

@abnerlee
Copy link
Contributor

abnerlee commented May 16, 2023

put into #1581 #1939

<details>
  <summary>expand</summary>
  
  ```python
  import math
  print(f'pi has value {math.pi}')
  ```
</details>

line 3 is an empty line, and, therefore the HTML tag is not correctly rendered, which is addressed in #1939.

@Pomax
Copy link
Author

Pomax commented May 16, 2023

No, it isn't.

#1939 is from 2018 and has not had anyone working on it since so it's not addressed there: it's raised there, and has since been ignored.

Please reopen this, or update that issue by assigning it to someone so it can finally be fixed after five years. And if you don't have the capacity: this is a bug in your GHFM parsing, not a feature request, it's been around for five years, people have been complaining about it for five years, this should be a p1 at this point, not a "we'll get to it when we get to it" because history clearly shows you are not getting to it at all.

@Pomax
Copy link
Author

Pomax commented May 16, 2023

(That might sound angry. That's because I am. If you sell a product that claims to support GHFM, and you get reports about your implementation actually not supporting GHFM, you should prioritise fixing that. Everything else derives values from how well you support GHFM. What you should not do is punt on it for five years and counting)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants