[qbasic_forever]

Markdown supports arbitrary HTML, you can do this:

    # Heading

    <script>
    const foo = 1 + 1;
    window.alert(`1 + 1 = ${foo}`);
    </script>

    Paragraphs of exposition.

In practice most markdown renderers will strip HTML or at least script tags as it is obviously a cross site security risk to allow github.com to serve user uploaded scripts without sanitization.

[reificator]

I think you're caught up on exactly the opposite of the complaint here. People aren't requesting JS execution, they have the various "notebook" solutions for that.

People are saying that triple backtick fenced code blocks are used to preserve whitespace and fixed width, usually with syntax highlighting as a bonus. That's the expected behavior.

However with the described mermaid support, it's taking a fenced code block with a mermaid tag and transforming it into a graph.

When inspecting the text content of a markdown file, there's no difference between a `javascript` tagged code block, a `haskell` tagged one, and a `mermaid` tagged one. But now when rendering, the mermaid one is special cased.

This is undesirable for multiple reasons, the most obvious being that it's now harder to write a README that displays mermaid syntax.

A good starting point would be either different syntax or a different tagging convention. For instance I think I saw `!mermaid` suggested, where the `!` would mean that the code should be interpreted instead of rendered as code.

I don't have a horse in the race of what this looks like, only that there should be a distinction between rendered and interpreted code blocks.

[qbasic_forever]

You're pushing a rock up hill--many markdown renderers natively support mermaid, plantUML, etc. using fenced code blocks.

If you explicitly want source code rendering don't add the mermaid tag to the block. There could be an argument that now you don't get syntax highlighting, but remember syntax highlighting itself is not part of any markdown spec and it differs wildly between implementations--there is no common grammar or spec for it even.

In all cases these are still valid markdown files and will pass through markdown processing, rendering, etc. systems without breaking them.

[reificator]

> You're pushing a rock up hill--many markdown renderers natively support mermaid, plantUML, etc. using fenced code blocks.

And yet Github's markdown support carries much more weight. Raising concerns at this point is a perfectly reasonable thing to do.