[dominicdewalt]

Hi all, I'm Dominic and I'm on the product team at Mermaid. I enjoyed reading a lot of your feedback!

It seems there's several good ideas and thoughts on the direction of the platform that we'd love to learn more about. If you have problems with the current product, improvement requests, or would like to chat then let's connect! Please email me at [e-mail] or book time on my calendar: (https://calendly.com/dominic-01w/mermaid-shapers-product-int...)

Thanks for taking a look at our latest release!

[thangalin]

Any idea when Mermaid diagrams will render outside of web browsers?

https://github.com/mermaid-js/mermaid/issues/2485

<rant> Aside, I'm the author of KeenWrite (https://keenwrite.com/), a Markdown text editor that allows embedding diagrams using the triple-backtick syntax. Here's a GraphViz example:

    ``` diagram-graphviz
    digraph {
        rankdir="LR";
        a -> b -> c;
    }
    ```

KeenWrite parses the `diagram-` prefix then passes the word `graphviz` to Kroki (https://kroki.io/), which has an API for rendering a variety of ASCII diagrams, including Mermaid. Meaning, if Kroki adds a new diagram type, KeenWrite gets it for free (without modification).

In Markdown, formatting a source code snippet entails using the standard syntax for code blocks:

    ``` graphviz
    digraph {
        rankdir="LR"
        a -> b -> c;
    }
    ```

GitHub created a de facto standard for Mermaid diagrams that breaks the convention of having triple-backticks followed by a language identifier to show the source code for that language in a monospace font. This was an unfortunate decision. </rant>

[baobun]

Hello Dominic.

Seconding the question on browserless rendering in the other comment. Having to (unseccessfully for us so far; the text renders incorrectly) tweak selenium setups to do headless builds is madness and I would have thought this to be top prio as a base feature beyond PoC for anything aiming for wide adoption.

[aloisklink]

I think there are two slightly different issues here!

1. SVGs generated by Mermaid use the SVG 2 features, but other than browsers, most libraries only support SVG 1.1 features, i.e. <https://github.com/mermaid-js/mermaid/issues/2102>, which is what the other comment mentioned.

2. Mermaid requires a browser layout engine to render the diagrams (your issue), i.e. <https://github.com/mermaid-js/mermaid/issues/3650>. This is something I also really want to fix (I maintain the [`mermaid-js/mermaid-cli`][1] project and we need to use Puppeteer/Headless Chrome to render mermaid diagrams, which isn't ideal.) However, I don't think this would be easy, since we'd need a browserless tool that supports a browser-like layout engine (although I'm hoping that [Servo][2] might eventually be able to support it).

And if you do want to do headless renders of Mermaid diagrams, I'd recommend using (or adapting, since the code is all MIT licensed and I'm not aware of one that uses Selenium):

- <https://github.com/mermaid-js/mermaid-cli>, which uses Puppeteer as the headless browser API.

- <https://github.com/remcohaszing/mermaid-isomorphic>, which uses Playwright as the headless browser API.

And make sure that whatever server is doing the headless renders of Mermaid diagrams has all the correct fonts installed!

[1]: https://github.com/mermaid-js/mermaid-cli

[2]: https://servo.org/

[jb3689]

I’d like to see better controls for keeping diagram components from colliding. I’m sure that’s a nontrivial ask, but I run into poorly placed components quite frequently, and I feel like that’d be a major selling point for Mermaid for me if you could solve it