Inconsistent with Commonmark Spec

[ikatyang]

Thanks for the awesome package, I'm able to implement markdown support for prettier using remark-parse (prettier/prettier#2943).

While I was implementing the pretty printer, I found there are some cases that parsed incorrectly according to the CommonMark spec 0.25:

(The commonmark option is linked to Commonmark Spec 0.25, so I guess it's based on 0.25?)

• _\__ (remark)
• commonmark spec example 160 (remark)
• commonmark spec example 239 (remark)
• commonmark spec example 270 (remark)
• commonmark spec example 275 (remark)
• commonmark spec example 323 (remark)
• commonmark spec example 389 (remark)
• commonmark spec example 416 (remark)

[wooorm]

Yes, that’s unfortunately correct. There’s a few cases where CommonMark differs.

remark-html tests for CommonMark compliance, but skips failing tests. You can run its tests to see the differences.

Through the time CommonMark was developed, a lot has changed, so more problems arise and I haven’t been able to keep up. Initially, when I added CommonMark support, complete CommonMark compatibility wasn’t a goal (because CommonMark wasn‘t all that common)

Commonmark is still in beta (not having a major semver yet), semver states:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

I’d like to add 100% CommonMark compat though, but that involves a rewrite of the parser, and that takes a lot of time. I envision in the future supporting just common mark with remark-parse, and moving the GitHub extension (now it moved to CommonMark as a base) to another project (remark-parse-github, remark-gfm?)

Anyway, I don’t have the bandwidth to do it myself currently, but I’d like assist anyone who’s interested in attempting it!

[geyang]

@wooorm Also there are quite a few CommonMark decisions that makes it hard to treat it as a AST. It would totally make sense to start another standard called "GoodMark" that makes CommonMark more regular and less contexual, and have a standard interpolation with embedded HTML, jsx, LaTeX and other languages.

For example, CommonMark's handling of html tags is quite annoying. It doesn't treat markdown and html as a tree, but segments of html string that is later strung together and then parsed by the html parser. This means <pre> tags and <div> tags are treated differently, and text in-between html tags are sometimes parsed as markdown but sometimes not.