I think this kind of thing is a bit more straightforward with Web Components, especially since the generated HTML can be rendered to Shadow DOM.
The PolymerElement project's <marked-element> has offered declarative client-side Markdown for years:
<marked-element>
<!-- content is in a script tag so inline HTML isn't instantiated -->
<script type="text/markdown">
# Hello
</script>
</marked-element>
How is this remotely elegant? You're including a script to render simple formatted text, something that can be accomplished by statically compiling from markdown to HTML before serving.
If you can serve static HTML, why not just do that?
It could be useful if you just want to edit a file in notepad and drop it on a CDN or fileshare without any tooling. I don't run a blog but it could be nice.
I'd definitely call it elegant, though not exactly minimal.
I helped run a fraternity website for a bit. If I could say, hey just download the source from chrome, tweak the bulletin in notepad, and upload it back to the ftp page that would have been great.
It also has the text in readable markdown. If you browse without JS it still works!
We used this for docs at a previous job... It was nice at the time... since not a lot of tools supported markdown.
However, in hindsight it sucks... all that documentation is so much harder to read in things like githublab... Those things render .md files just great, however, all these old docs look like html and require JS to render...
Just write pure markdown in .md files... view them w/ tooling, don't build tooling into the file...
On my browser, this page flashes raw HTML before it displays the rendered page - not a nice experience. I don't like the idea of this at all, anyway - surely it's better to render content once rather than render it thousands or even millions of times clientside?
FYI, if you want to src attribute to load markdown files you need to build js files yourself as the js file in the CDN doesn't have the feature for some reason.
I don't see how this is SEO friendly, as claimed by the site. Is the idea that because the text is already on the HTML isn't not a negative from an SEO point of view?
I've been using this for about 2 years now for my own personal documentation. Now I've switched over to using VS Code and it's Markdown Preview function but if you want to quickly render Markdown as a webpage this is a great tool!
Off topic but I never knew the term for this. The cbcnews.ca site got rebuilt in react recently and the result has this one bug where when loading, some headlines flash an entirely different but also valid headline for the same story for a split second. When it comes to news, a FOUT like that makes me rather paranoid about maybe I'm getting a tailored headline for my demographic.
It's been really common for years to split test headlines[1] for content. Even most email marketing platforms have a variation of it, where they stagger out emails, sending out a few variations with different subject lines to a subset of users first, identifying the one with highest engagement, then releasing the email to the remainder/bulk of your email list using that subject.
I wouldn't put it past the major publishers to have moved beyond A/B testing for an overall headline winner to more segmented optimization based on tying A/B performance to first and third party data they have available on you, and further optimizing their headlines to reflect whatever performed well for traffic like you, rather than just performed best overall for all traffic.
I don't think it has any FOUT, because the whole element is styled with "display: none;". Only after the JS is parsed, it formats the Markdown code and then re-display it.
I noticed it, though my work PC is slow as molasses.
Based on how Strapdown appears to work, it appears to be the delayed CSS load that causes the problems.
I believe that the problem could be alleviated by adding the CSS link tags to the head of the document, when you're happy with the final product. Looks like you should only need bootstrap and whatever you choose from bootswatch.
This feature is obsolete. Although it may still work in some browsers, its use is discouraged since it could be removed at any time. Try to avoid using it.
* It has been deprecated since HTML3.2 and was not implemented in a consistent way. It was completely removed from the language in HTML5.
* Use the <pre> element or, if semantically adequate, the <code> element instead. Note that you will need to escape the '<' character as '<' to make sure it is not interpreted as markup.
* A monospaced font can also be obtained on any element, by applying an adequate CSS style using monospace as the generic-font value for the font-family property.
I may be totally off track here, but I am thinking that the <xmp> tag is only used for the parser to identify which theme the author wants to use? I am assuming that the end HTML just strips out the xmp tag and inserts the relevant bootstrap CSS/JS links in there to match the theme, so the actual xmp tag is never passed across to the browser?
Presumably it was chosen because it also allows the author to include HTML tags inside Markdown (somewhat common in Markdown usage) with the browser (mostly) ignoring them. It's part of why many other options using <script type='text/markdown'>, though at least in SCRIPT's case it hasn't been deprecated since HTML 3.2.
Neat looking. This may be useful for search discoverability also. Not all engines enable javascript and for the ones they do, it is probably not enabled for all pages, so they'll end up parsing "clean" markdown.
The PolymerElement project's <marked-element> has offered declarative client-side Markdown for years:
https://www.webcomponents.org/element/PolymerElements/marked...For math, you can do a similar thing with Katex: https://github.com/justinfagnani/katex-elements