This thread reflects latest & actual state about parser, been done by me & Alex.
Why it’s done
- Because we needed easy way to modify syntax & output. Almost all parsers i know have hardcoded logic.
- Because i wished to improve my skills in writing high-speed js, and this project was good for it.
Key differences with reference parcer
- Focused on producing safe HTML out of box in one step. Instead of universal data abstraction layer.
- Token steam instead of AST. More simple (IMHO), and enougth to support local transformation filters.
- It’s still technically possible to convert data into commonmark ast, but no reasons to do it in core.
- HTML disabled by default. Any features can be added via plugins in secure way.
- We can’t run owasp validator in browser, it’s more simple to disable html at all.
- But it’s not a big problem. In 99% people use HTML because it’s hard to modify parser.
markdown-it
has no such problems. You will be able to do everything without html, in secure way.
- SourceMapping limited to line numbers only (no time, not needed now for our tasks).
- High speed (it’s actually faster than all available JS parsers for markdown).
- Very easy to modify. Everything!
With default settings parser is more close to GH’s, and tends to support the most demamded features, not yet covered in CM spec. But it still has strict CM mode, and existing syntax is periodically syncronized with CM on spec updates.
This parser is not better or worse than reference one. It have different goals, different priorities, different architecture and so on. We have no primary goal to promote new standard, but we like to follow CM spec.
PS. Of cause, tons of thanks to @jgm for his outstanding efforts on writing CommonMark spec.