It would be nice to have HTML passthrough as an option

[ell1e]

It would be nice to have HTML passthrough as an option at least, and here's why:

I'm currently looking around for markdown libraries, especially very simple ones with no complicated build systems or dependencies for better portability to more obscure targets like Android and others without tons of manual adjustment and build system headaches. However, I only care about HTML final output (so passthrough makes sense there in principle), and I care about being able to extend the parser. The easiest way to extend however is to preparse the original markdown with my own extension handler, replace only the extended stuff to inline HTML, and then run the regular markdown parser to do everything else. But this only works if HTML is allowed to pass through unaltered.

I understand if that's not possible in the scope of this project, but I just wanted to bring it up in case it was. This seems to be one of the few single file parsers that are 1. still maintained, and also 2. try to stick somewhat to commonmark as a standard.

[michaelrsweet]

Supporting embedded HTML in markdown is, in general, very hard to do safely (which is why most markdown code that does support HTML doesn't provide any safety guarantees...)

I'm not keen on adding support for HTML at the moment, but I'll keep this issue open for potential future usage. I'm also not sure how to best represent the HTML so that the content can otherwise be used - do I just support inline HTML elements or do I try to support arbitrary HTML?

[ell1e]

If you mean by safety that the HTML isn't filtered or checked for actually having legal tags or not just contain evil JavaScript, that would be fine, I would consider that a feature (to be able to pass in JavaScript, for example). But it shouldn't crash or memory leak mmd no matter how it looks like or how deformed the HTML is, e.g. broken open tags are fine to cause nonsense to the output but shouldn't cause a crash or leak either.

I think for my use, HTML contained to one line left alone would be enough (as in, if it goes across multiple lines it just breaks in some way that causes an invalid output that might ruin the HTML but doesn't cause crashes/leaks), as long as both html entities and tags can pass through if they all are crammed into one line with no \n or \r\n breaking them up.

I think that is also how some other parsers I've tested handle it? Like pandoc.

But if this doesn't fit your project's scope that's fine, then don't do it. I'm not locked in to a particular library, and yours doesn't need to somehow be forced to fit my purpose either. The code looks kind of nice however, you seem to e.g. properly handle allocation failures and actually have some tests, so that's promising.

For what it's worth, I'm actually also kind of blocked on #12 anyway although that can be worked around with temporary folders, albeit at a performance cost of course.