Closed cheloizaguirre closed 10 years ago
The HTML elements "details" and "summary" are part of HTML5 which kramdown only supports partially. I have looked at the spec and a fully correct implementation is not possible for "summary" since it supports two different content models.
This will be fixed in the next version so that both elements are recognized as having a block content model.
@cheloizaguirre Please keep in mind that you will still have (i.e. after fixing this in kramdown) to use the parse_block_html option or that you need to a "markdown" attribute to the <summary>
and <details>
elements!
Hello there. Seems like it's been a while since this issue was closed. It is not clear to me, however, if Kramdown supports Markdown inside <details>
for collapsible blocks.
While testing this last night, I found GitHub rendered the markdown inside properly when browsing the repo in GitHub.com, but it renders as plain test when browsing the same file on GitHub Pages.
Browsing at GitHub.com:
Browsing on rendered GitHub Pages:
If Kramdown supports Markdown inside <details>
, what do I need to do for it to render properly?
@eneko Just so that you know pictures are quite worthless when it comes to determining problems. Better show the input, the false output and the expected output as text.
As for your question: As written in https://github.com/gettalong/kramdown/issues/155#issuecomment-55021131 you need to enable the 'parse_block_html' option.
Thanks! Yeah, I thought of pasting some code examples, but too much escaping to show the issue. Took the lazy path :)
Thanks, if I understand it properly, the _config.yml
should look something like this, correct?
markdown: kramdown
kramdown:
parse_block_html: true
I assume there is no other way to get this working on GitHub pages that do not have a config file, correct?
For Jekyll related questions please ask on some Jekyll forum or something similar since I don't use Jekyll as my static website generator.
@gettalong sorry to bother you again. Do you have any examples of this feature working with Kramdown, whether is with Jekyll or not? I am failing to get it to work, not sure what I'm missing.
@eneko You can always use the kramdown binary to check whether the problem lies with kramdown or the tool that uses kramdown, like this:
$ echo -e "<details>\n# Header\n\nPara*graph*\n\n> quote\n</details>" | kramdown --parse-block-html
<details>
<h1 id="header">Header</h1>
<p>Para<em>graph</em></p>
<blockquote>
<p>quote</p>
</blockquote>
</details>
As you can see the kramdown markup is correctly processed within the <details>
tag. Also have a look at https://kramdown.gettalong.org/syntax.html#html-blocks
Ok, I think I found the problem, thanks for the command line example.
The HTML <details>
tag is usually paired with an embedded <summary>
tag.
Looks like if a <summary>
tag is present when running Kramdown with --parse-block-html
, both <summary>
and <details>
tags are mistakenly escaped.
$ echo -e "<details><summary>Collapsed Block</summary>\n\n## Header\n</details>" | kramdown --parse-block-html
<details>
<summary>
<p>Collapsed Block</summary></p>
<h2 id="header">Header</h2>
<p></details></p>
</summary>
</details>
Warning: Found no end tag for 'summary' (line 1) - auto-closing it
Warning: Found no end tag for 'details' (line 1) - auto-closing it
Warning: Found invalidly used HTML closing tag for 'summary' on line 1
Warning: Found invalidly used HTML closing tag for 'details' on line 4
The nested <summary>
tag is triggering the escaping issue, maybe because it is also identified as a block tag.
Nested <details>
blocks, on the other hand, work as expected:
$ echo -e "<details>\nStart.\n<details>\nNested *details*.\n</details>\nEnd.\n</details>" | kramdown --parse-block-html
<details>
<p>Start.</p>
<details>
<p>Nested <em>details</em>.</p>
</details>
<p>End.</p>
</details>
@gettalong, let me know if you would like me to open a new issue, if that makes things easier.
As stated in the syntax documentation, the closing tag for an HTML tag must start on a new line if the contents is parsed as block elements:
$ echo -e "<details><summary>Collapsed Block\n</summary>\n\n## Header\n</details>" | kramdown --parse-block-html
<details>
<summary>
<p>Collapsed Block</p>
</summary>
<h2 id="header">Header</h2>
</details>
Ok, thanks. That is pretty close to the desired output. Is there any way to prevent the <p>
tag from being added inside the summary? By doing so, it renders the summary text on the next line than the details caret, instead of next to it.
Maybe summary
shouldn't be treated as a block text, since it should be next to the expand/collapse caret "▶︎".
How elements get rendered depends on the CSS; therefore kramdown can do nothing in this regard.
If you don't want to parse the contents of an HTML tag as block elements, you should use the 'parse_block_html' option. Alternatively, you can specify markdown="span"
:
$ echo -e "<details><summary markdown='span'>Collapsed Block\n</summary>\n\n## Header\n</details>" | kramdown --parse-block-html
<details>
<summary>Collapsed Block
</summary>
<h2 id="header">Header</h2>
</details>
Oh man, that works like a charm! 👍. Thank you very much!
Here is some working examples: https://github.com/eneko/MarkdownGenerator/blob/master/docs/structs/MarkdownHeader.md http://www.enekoalonso.com/MarkdownGenerator/structs/MarkdownHeader.html
adding markdown='span'
so <summary/>
become summery <summary markdown='span'/>
to work this out is nice workaround, but we are in 2021 and it should not be neccecary. it also tool me A LOT of time to find out.
for someone else trying to find a solution for github comments. I found that adding a non-breaking space character (nbsp) aka extended-ascii code 255
character right before <details>
makes it work. ALT+255 on Windows. It's kinda ridiculous but yeah.
(ALT+255)<details><summary>Summary Goes Here</summary>
### Header
* option 1
* option 2
* option 3
</details>
becomes
Summary Goes Here
Ref : https://github.com/root-project/web/pull/529#issue-832096581 (Thanks :clap: )
If we do something like:
<details markdown=1><summary markdown="span">Our summary here</summary>
our markdown text here :
```bash
echo "Hello markdown"
``'
- markdown1
- markdown2
- markdown3
html tags also supported
<ol>
<li> hello html list tag1</li>
<li> hello html list tag2</li>
</ol>
</details>
it will be rendered something like :
Edit - 1 - Its to rendering properly on github page
See : https://pipewire-debian.github.io
@souravdas142 your solution worked perfectly for me as part of GitHub /github pages with markdown
to whom it might concern, I've solved the issue by adding markdown=1
to an inner <div>
:
<details>
<summary><strong>A strong summary</strong></summary>
<div markdown=1>
This is fine:
* first
* second
</div>
</details>
I put in my GH Pages/Jekyll's _config.yml
:
markdown: kramdown
kramdown:
input: GFM
So for me, the following does not render h1 (also confirmed by running kramdown --parse-block-html
locally)
<details markdown="1">
<summary markdown="span">
# Header
</summary>
Para*graph*
</details>
The following renders markdown inside summary, but it doesn't make the h1 a span, so is quite weird:
<details markdown="1">
<summary markdown="1">
# Header
</summary>
Para*graph*
</details>
How can I get both of the two worlds and get markdown rendered both in summary inline and in details body? Thanks :)
@vadimkantorov I'm not sure what you want to achieve. If you use markdown="span"
, you tell kramdown that the contents should be parsed like a paragraph, i.e. it contains only inline content. However, you want to create a heading element which is a block level element and, from your examples, everything is working as expected.
I'm trying to use the
and HTML tags, but any markdown inside of them that I used is ignored. Here's a sample of what I'm trying to do:
The output of that ends up being:
I've tried using the parse_block_html option and adding markdown="1" or markdown="span" to the HTML tags, but the text inside there just gets ignored. I looked in https://github.com/gettalong/kramdown/blob/master/lib/kramdown/parser/html.rb#L57 and it seems like
should be working as expected, though is not there, so it might be getting ignored alltogether.
I'm totally willing to look into it myself if you can point me in the direction of a good place to start. Thanks!