```!dot
(Markup)
```
So, the question is would you rather have SVGs inline?
Personally I think the reference to another file is a perfectly fine compromise, as the content is sufficiently different to no longer be markdown.
Also, I personally hate markdown tables since editing even a single cell means that I likely have to then resize either the entire row or the entire column, or both. So when I do need tables I use HTML tables anyway.
At any rate, a middle-ground might be to have the diagram source as references at the end of the document, and reference those from the use site, like `![Chart][#chart]` or something. So you don't have to see the diagram source inline if you don't like it, but it's still there in the same file.
Another similar example, all of VSCode's configuration files are called filename.json but they aren't actually json (any spec compliant json parser would barf on them).
They could just have easily named them filename.jsonc (or whatever they actually are) but they didn't so we're stuck with all these .json files that json parsers won't actually parse and special hacks to validate them differently based on like if they're in a .vscode folder or if their name is some specific filename.
Unfortunately there's no way to wrangle millions of programmers so we're stuck with whatever bad decisions become popular.
IF that's not clear above, for example, trailing commas and comments are not allowed in JSON but they are in JSONC. You'd like your editor to highlight errors. Typically this is done by filename extension. .json = comments show as errors, .jsonc = comments OK. But VSCode named it's .jsonc files as .json so every editor that wants to be able to show if there are errors in your file now needs some random heuristic to decide how to interpret the file..... all because of a bad decision by 1 or 2 programmers that ended up being popular and now their too entrenched to fix it.
The same thing is true here. ``` is supposed to mark a codeblock as in show the text as is, whitespace as is, line breaks as is. If you want to write a tutorial on how to use mermaid in markdown you'd want ``` to show the mermaid source. Use some other tag for rendering. But now where stuck with an exception and more will be added.
And before you go say "there's no official spec", so what!? It's called being consistent and interpreting the contents of a ``` block is inconsistent.
Why don't we just go back to xml and provide decent structured editors?
```ruby
# syntax highlighted as ruby
a = 1 + 1
```
```js
// syntax highlighted as js
a = 1 + 1
```
```!ruby
# evaluated
as ruby
a = 1 + 1
# renders 2 because of implicit return?
```But in the end went with simple. There will be a very limited subset that will render this way - executing raw code without the users permission in the browser just opens up too much attack surface area that we’d need a very compelling use case to do the security work necessary to make it protected (even if that was possible)
<pre><code> your mermaid code <span class="foo">with highlighted</span> sections </code></pre>
Use a tool like pygments to generate the highlighted HTML (assuming there even is highlighting for mermaid syntax).
What you're asking for is an uncommon edgecase that's not what people want in 99% of circumstances (instead they want the rendered chart). Markdown still gives you the HTML escape hatch so use it. Sure it's not pretty but it's no worse than if github didn't support highlighting mermaid source anyways.
If you don't want highlighting just put a fenced code block without the mermaid info string. It will render as unhighlighted code. IMHO that's what you'd want as a workaround to demo source like in a mermaid readme.
It's how it worked before this change, and how it works for every other language in Markdown. This is taking away functionality with no reasonable replacement and creating a special-case gotcha in the Markdown syntax (the same syntax could produce highlighted code or a rendered image depending on the language and what features any particular Markdown implementation supports), and it's not clear why this is necessary when something like ```!mermaid would work just as well to trigger rendering. It's unforced bad language design.
> Use a tool like pygments to generate the highlighted HTML
This requires hardcoding colors into the generated HTML, so the highlighting won't match the color theme of the context that the document is embedded in, breaking e.g. dark mode.
But for "markdown the language" having a standard syntax for embed/evaluate along with prettify/highlight would've been nice - effectively a standard markup for multi-language "notebooks"/literate programs (maybe we need a triplet: format, render/embed, transclude/literate programming).
Github could then opt-in to highlighting the N languages they do, and initially only try to render mermaid graphs. Then perhaps also graphviz graphs. Etc.
[1] I'm sure one could do some minor DOS at least with a 500 mb graph..
https://squidfunk.github.io/mkdocs-material/reference/code-b...
``` py hl_lines="2 3"
def bubble_sort(items):
for i in range(len(items)):
for j in range(len(items) - 1 - i):
if items[j] > items[j + 1]:
items[j], items[j + 1] = items[j + 1], items[j]
Some tools in the computational notebook space use markdown with fenced code blocks as blocks of executable code, see for example jupytext: https://github.com/mwouts/jupytext/blob/main/docs/formats.md or myst markdown: https://myst-parser.readthedocs.io/en/latest/syntax/syntax.h... or nbconvert: https://nbconvert.readthedocs.io/en/latest/
What’s debatable is what the spec does with the “info” section.
# Heading
<script>
const foo = 1 + 1;
window.alert(`1 + 1 = ${foo}`);
</script>
Paragraphs of exposition.
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.
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.
And yet Github's markdown support carries much more weight. Raising concerns at this point is a perfectly reasonable thing to do.
```math
-b \pm \sqrt{b^2 - 4ac} \over {2a}
```
JavaScript ; poem ; ’90s email ; OP ; latex math ; ditaa
One thought though, on the syntax. Wouldn’t it be a bit odd if suddenly this line in a README.md:
Rendered as: ? Isn’t that kind of what we’re doing here with the mermaid source tag? That tag is for showing source code, no? Feels like there should be another tag for rendering it.