1. You are editing documents locally on your computer. This lets you double-click to view nice markdown in a web browser with a `file://` url.
2. You are editing a website, but don't have control over the server-side code.
3. You don't want to install a markdown rendering library on the server.
You don't have control over the server-side code, but it will let you inject <script> tags into the content? That seems a bit weird.
Their documentation was written in markdown and the site was hosted on static hosting, so no server-side conversion.
Although the web page chrome (navigation, etc) was in HTML, they wanted the documentation to be in markdown under the hood after upload. They didn’t want to use any kind of conversion prior to uploading because they needed to make on-the-fly changes to the documentation after upload without writing in HTML.
So we opted to go with client-side markdown to html conversion on pageload. complete with a clickable legend and tabs to switch between language implementations for code examples.
Putting the markdown inside regular page formatting tags wasn’t reliable, as different browsers did different things to the content (for example some browsers converted “&” to “&” and the indentations for code was not respected). So we had to store the markdown in some sort of preformatted tag block.
However <pre> required special escaping of code characters ( <, >, &, etc).
So we opted to go with using a little-known <xmp> tag to store the markdown as search-engine indexable code. Since content inside <xmp> will be read as plaintext instead of being formatted by the browser, it was also great for being the input of a client-side markdown-to-html converter.
It worked quite well. If you want to see it in action it’s at https://www.genivia.com/dev.html
Main use-case is when I want to share a markdown doc in a private GitHub repo, with a public url e.g http://oscarmorrison.com/md-page/oimasdoijasdmadeupurl-01231...