Replies: 3 comments 4 replies
-
I'm not against it: I dream of having a way to describe diagrams inside a document. Nevertheless, it would be interesting to know where we could use it on MDN. Adding it to create one UML diagram doesn't seem like a good trade-off for the added complexity. I can think of a few other places this could be handy (like for network diagrams, handy in fetch, XHR, HTTP, …) I have a few questions:
|
Beta Was this translation helpful? Give feedback.
-
It looks like a nice to have feature. Mermaid has support for font awesome style custom icons so many existing png, gpg files can be converted to the marmaid code. This will reduce repo code size a lot. Implementation approachesWe have three options to implement this in yari. b. Before doing normal builds in yari, pass the content md code through mermaid-cli. c. Use .mmd(mermaid diagram) files like we use png, gif, svg etc. Convert them to svg during build. Let me know if I've missed anything? Counter argumentDon't hate me for this. Regarding strategy a. and b. above, current prod build is ~1hr long and dev build is ~1hr30min long. Processing mermaid code blocs will add to the build time a lot. When one day we'll have thousands of mermaid blocks all over the repos then this will become a real issue. We can ignore lengthy prod builds but longer dev build will really make working on yari a nightmare. We don't have true dev mode in yari ATM. 😡 Regarding adding complexity concern raised by @teoli2003. I mean to keep the platform simple, we can always use Mermaid offline to generate those beautiful illustrations and use the generated SVGs in content. |
Beta Was this translation helpful? Give feedback.
-
Going back to this, @OnkarRuikar.
It's not a big deal—browser compatibility table doesn't work either, neither do all the interactive/live examples. Experience is degraded but no critical information is lost anyway. If you still don't like it let's look at the next option. I personally don't have an opinion between 2 and 3, although I believe 2 works better than 3, because 3 is referencing a file that doesn't exist until build-time (I assume you still write Regarding build time. Yari really needs an incremental build mode; I don't know how it does this, but doesn't Yari do partial builds in Really, I don't care if we support Mermaid compilation in Yari, but I need to support Mermaid rendering, even if that means I need to compile Mermaid to SVG by hand. What I don't want is having to copy the SVG source into Markdown just to make it selectable/clickable. If we can make
That's the major point yes. Apart from that, looking at the many existing custom diagrams created using various softwares:
|
Beta Was this translation helpful? Give feedback.
-
This is discussed with @schalkneethling on Slack.
Mermaid is a tool for generating SVG diagrams from a DSL. GitHub has added support for it for just over a year: https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/
Why do we want to have it built-in? Because this generates the SVG markup within the HTML, instead of the traditional way of adding an
<img>
element that links to the SVG. The benefit is that the SVG text is selectable, and any<a>
links within the SVG would be clickable. There doesn't seem to be a way to do this in MDN yet, without cluttering the MD source with a chunk of copy/pasted SVG.Here's an SVG I'm developing:
Where every box would be a clickable link to its class page.
Beta Was this translation helpful? Give feedback.
All reactions