Aidan Woods

GitHub renders these like: ```html [https://domain.com/]("foo bar") [https://domain.com/](foo bar) https://domain.com/ ``` So I think this is the expected result here. The first two aren't valid links ([according to CommonMark](https://spec.commonmark.org/dingus/?text=%5Bhttps%3A%2F%2Fdomain.com%2F%5D(%22foo%20bar%22)%0A%0A%5Bhttps%3A%2F%2Fdomain.com%2F%5D(foo%20bar)%0A%0A%5Bhttps%3A%2F%2Fdomain.com%2F%5D(foo))), and...

My current plan to resolve this is to formalise a few things like `Block`, `Inline`, `Line`, ... with an interface or dedicated type. WIP over at #685

More or less, now that PR is (hopefully :) ) finalising, I can start writing up some docs around building custom components that can be integrated into the parser (both...

Probably not as default behaviour, but would be interesting as optional behaviour. I'm not convinced the linked spec is well defined though: how should the row ``` | foo |>|

This should be resolved by the changes #172, the HTML encoding has been completely rewritten. I'll leave this open until that is merged.

@Daniel-KM > Note that because it allows any attributes and potentially any xss attacks, the merge will be released after the upstream of parsedown (see erusev/parsedown#495 or erusev/parsedown#161). If I'm...

> Of course, this is not for public writing, but for controlled edition. Looks like (from a cursory look at the code) that there is no setter to turn this...

Yup! Once Parsedown 1.8 is released I hope to be able to take a look at the things in this PR :)

I don't foresee any issues with supporting this for fenced code blocks, I'll have a go later today. As @lakhman points out, this is something that *should* work per the...

Apologies, correction: it appears that rule 15 does not apply because the given example does not overlap *in the way specified*. In which case rule 13 should be applied as...