Canvas/SVG renderer

[fabiospampinato]

Is your feature request related to a problem? Please describe.

The current way diagrams are rendered is too reliant on the DOM, that causes problems because it makes Mermaid conflict with the host app (CSS conflicts that are hard to debug, XSS vulnerabilities, lots of not-really-necessary layout recalculations that slow things down massively etc.).

Describe the solution you'd like

In my opinion Mermaid should at most use a detached <canvas> and that's it. I think ideally the library would either support rendering the diagram on a provided canvas or output an SVG as a string, potentially still using a <canvas> internally for measuring the length of text, which I think is what the DOM is mainly used for currently basically, like if you know how long texts are the DOM can be dropped entirely I think.

That would get rid of all the issues I mentioned:

• CSS conflicts: the SVG can be rendered in an isolated manner, and stuff painted inside an <canvas> is just not susceptible to CSS rules at all.
• XSS vulnerabilities: it becomes trivial to get rid of these, it's impossible to inject executable stuff in a canvas, and if the SVG is rendered with an <img> tag or something like that it becomes instantly XSS-proof too, no external HTML sanitizer necessary (which is also a bit of a gamble, no way these things are 100% impenetrable).
• Layout recalculations: if a canvas is used for measuring things that's completely detached from the DOM, just by using a canvas for measurements (and potentially painting too) Mermaid would be quite a lot faster too.

Describe alternatives you've considered

Dropping Mermaid, the current renderer is too problematic and Mermaid is pretty heavy for my use case (both in terms of bundle sizes and performance). Unfortunately if there's a better alternative around I haven't found it, and at the moment I don't have the resources to write my own thing or contribute a canvas-based renderer to Mermaid.

Additional context

N/A.

[hikerpig]

I think mermaid's codebase relies too deeply on D3 and the browser API. I've written a pretty early-stage kind-of-copycat of Mermaid which is called Pintora. Currently only simple sequence / er / component diagram is supported. I chose to abstract a renderer layer so I can replace this with any implementations in the future, currently @antv/g-svg and @antv/g-canvas are used. The canvas output is fine in my opinion.

[fabiospampinato]

I think it's probably true that Mermaid currently relies too much on the browser and D3, and switching to a canvas renderer is probably too big of an undertaking, but it seems to me like having a canvas renderer, or something similar that's more independent from the DOM, is a necessary requirement for having a ~perfect diagrams library, so somebody has got to do it eventually.

@hikerpig Best of luck with your project, if you can manage to make it fully compatible with mermaid or manage to make an overall better library I'd be very happy to integrate that in Notable if you like.

[hikerpig]

@fabiospampinato Notable is so nice 👍. Honestly, I wouldn't dream of being fully compatible with mermaid as it has so many intricate details... I'm trying to make it as extensible as possible, though. Hoping it would not be such a pain when adding new diagram types.