Use different Markdown parser about catalog HOT 4 CLOSED

As far as I can tell, mdast can't parse HTML out of the box and I didn't find a plugin for it. But I think this is not that essential. Maybe @naehrstoff can give a few examples where this would have been useful in the past?

However, mdast seems to be the most extensible option out there. It has some cool plugins:

• https://github.com/wooorm/mdast-slug (useful for #28)
• https://github.com/wooorm/mdast-zone (could be used for #29)

from catalog.

Ping me for help! mdast too, however, doesn’t care about strings of HTML (or their validity), and in fact I’m not very interested in adding that as it’s beyond the scope of markdown, and possible even quite dangerous.

Most importantly, mdast is indeed quite extensible, and I’m always interesting in more ideas 😄

from catalog.

We've mostly encountered this in polishing styleguides:

• We're not able to use text like "Me & Co." because this will be turned into and displayed as "Me & Co." or something. Somewhat solved by using "Me + Co."
• Ensure nice typography as in Mrs. Ripley → Mrs. Weaver. Might be able to use Unicode for this instead
• Add special elements unique to a given styleguide as in <span class="highlight">Wow</span>

These are small annoyances and not that important individually, but they accumulate and differ from what is to be expected from Markdown, so they are quite unexpected to novices and slightly annoying to more experienced writers.

@wooorm Thanks for offering your help! If we were to tackle this issue, we'd have to be able to somehow turn HTML elements within, say, a Markdown paragraph into React components. But this will probably add too much unnecessary complexity … I guess what it means for mdast is that the AST would have to go deeper and turn HTML within said paragraph (e.g. the & or <span />) into a syntax-tree-thing. We'd then need to write a plugin that turns these things into React components.

Markdown usually doesn't have to concern itself with this transformation because it's just HTML, so content within the paragraph will get parsed by the browser just fine, but in our case we'd need to be able to turn it into React components. Sigh.

Yeah, not sure this is worth pursuing, just wanted to explain a bit of the reasoning behind it 😄

from catalog.

I did some research and experiments, and came to the conclusion that currently it's not worth it to change the Markdown engine.

I mainly looked at remark wit remark-react (formerly mdast) but it has two major drawbacks:

• Just replacing marked with remark adds 91KB to the minified bundle size
• I added remark to the benchmark suite at https://github.com/markdown-it/markdown-it, and it's ~30 times slower than marked (maybe I did something wrong?).

These are quite the deal breakers for me.

Another good contender would be markdown-it but it's also a lot bigger than marked. Its main advantage is full CommonMark compliance but I don't think that's super-important for us at this moment.

Therefore I suggest we just keep marked (it's not very actively developed but it still works).

from catalog.