Collapsibles generate HTML code, and embedded tags convert to HTML as well #187

locodarwin commented 2026年06月29日 05:17:28 +02:00

Description

Collapsible sections generates HTML and will cause all subsequent embedded tags to generate HTML in the source. Interestingly, callouts do not do this unless embedded themselves (or if a collapsible is embedded within them).

Steps to reproduce

Any collapsible section with embedded tags will do, but an especially interesting case is nested collapsibles:

1. Create a new note
2. Insert a collapsible section with slash / tags or by clicking the button in WYSIWYG mode
3. Add another collapsible (or callout) inside the first collapsible
4. Add some other / or typed tags/keystrokes, too, for the fun of it
5. Switch to source mode; notice the source is pure HTML for all tags

Expected behavior

This might be the expected behavior. The effect, though, is that the resulting markdown output potentially loses portability in many other MD renderers. In fact some renderers that do render HTML to some degree will get completely borked, especially with embedded collapsibles or other HTML classes. It's up to the Helixnotes developer(s) to determine if this is accepted behavior, and to what extent. I understand adding HTML into markdown isn't exactly controversial, and it's expected for some features (e.g. table formatting), so this really comes down to intent.

Perhaps this is useful; it's clear that Helixnotes recognizes and renders standard HTML tags including <div> and classes, which allows for all sorts of creative rendering ideas for future development (e.g. Bootstrap elements and so on). However, this does seem to stray away from what appears to be the intent of Helixnotes and frankly sticking with pure markdown (and extended markdown of one or more of the extended flavors?) would suit me fine personally.

Related

• Continuous nesting of collapsibles (embed recursion) will actually render fine - tested up to 8 nestings
• The generated HTML tags in do not appear to create any lasting issues with rendering in Helixnotes

Tested on

Windows 11, Linux (AppImage)

Attached screenshots

Attached screenshots just demonstrate the effects of embedded recursed collapsible sections (including callouts).

### Description Collapsible sections generates HTML and will cause all subsequent embedded tags to generate HTML in the source. Interestingly, callouts do not do this unless embedded themselves (or if a collapsible is embedded within them). ### Steps to reproduce Any collapsible section with embedded tags will do, but an especially interesting case is nested collapsibles: 1. Create a new note 2. Insert a collapsible section with slash `/` tags or by clicking the button in WYSIWYG mode 3. Add another collapsible (or callout) inside the first collapsible 4. Add some other `/` or typed tags/keystrokes, too, for the fun of it 5. Switch to source mode; notice the source is pure HTML for all tags ### Expected behavior This might be the expected behavior. The effect, though, is that the resulting markdown output potentially loses portability in many other MD renderers. In fact some renderers that do render HTML to some degree will get completely borked, especially with embedded collapsibles or other HTML classes. It's up to the Helixnotes developer(s) to determine if this is accepted behavior, and to what extent. I understand adding HTML into markdown isn't exactly controversial, and it's expected for some features (e.g. table formatting), so this really comes down to intent. Perhaps this is useful; it's clear that Helixnotes recognizes and renders standard HTML tags including `<div>` and classes, which allows for all sorts of creative rendering ideas for future development (e.g. Bootstrap elements and so on). However, this does seem to stray away from what appears to be the intent of Helixnotes and frankly sticking with pure markdown (and extended markdown of one or more of the extended flavors?) would suit me fine personally. ### Related - Continuous nesting of collapsibles (embed recursion) will actually render fine - tested up to 8 nestings - The generated HTML tags in do not appear to create any lasting issues with rendering in Helixnotes ### Tested on Windows 11, Linux (AppImage) ### Attached screenshots Attached screenshots just demonstrate the effects of embedded recursed collapsible sections (including callouts).

ArkHost commented 2026年06月30日 12:44:08 +02:00

Hello,

You're right, this is expected behavior. Collapsible sections have no standard Markdown equivalent, so we serialize them as <details>/<summary> HTML.
When a collapsible contains other elements, the entire subtree falls through to DOM serialization, which is why callouts inside collapsibles also become HTML (callouts on their own serialize as > [!type] Markdown). Raw <details> degrades gracefully in renderers that support HTML, so we're keeping it as it is for now.

Leaving this open as a design discussion item.

Hello, You're right, this is expected behavior. Collapsible sections have no standard Markdown equivalent, so we serialize them as `<details>/<summary>` HTML. When a collapsible contains other elements, the entire subtree falls through to DOM serialization, which is why callouts inside collapsibles also become HTML (callouts on their own serialize as `> [!type]` Markdown). Raw `<details>` degrades gracefully in renderers that support HTML, so we're keeping it as it is for now. Leaving this open as a design discussion item.

locodarwin commented 2026年06月30日 17:22:49 +02:00

Understood, thank you. Recognizing that there will be some need to allow for general HTML to render features that markdown doesn't cover, it becomes a question of what extent you wish to allow non-markdown features. I support any direction you choose, but I can readily see the slippery slope. Do you have some thoughts already as to where you want to draw the line?

Understood, thank you. Recognizing that there will be some need to allow for general HTML to render features that markdown doesn't cover, it becomes a question of what extent you wish to allow non-markdown features. I support any direction you choose, but I can readily see the slippery slope. Do you have some thoughts already as to where you want to draw the line?