✨ Your Markdown, your syntax — introducing inlineRules v2

[do-md]

Every Markdown tool eventually hits the same wall: the inline syntax is fixed. You want highlights, mentions, comments, wikilinks — and the usual answers are all bad: preprocess the text, fork the parser, or bolt on raw HTML. With @do-md/core-react 0.6, DOMD takes a different path: inline syntax is now a first-class extension point of the editor itself.

The design in four ideas

1. Standing on the de facto standard.
Parameters follow the Pandoc/Djot inline-attribute family — the closest thing extended Markdown has to a standard, the same convention you already know from Pandoc, Quarto, kramdown and markdown-it. One grammar scales smoothly from a one-word tweak to a fully attributed, typed span:

==highlight==                              plain highlight
=={red}highlight==                         tinted — a positional param
=={.comment author="Alice"}highlight==     a semantic type, with attributes

2. Syntax and semantics are orthogonal.
Delimiters carry no meaning of their own. A .word selects a variant — a semantic type registered as plain data — and the same type attaches to whichever delimiters you like:

=={.mention id=1}Alice==   ≡   <{.mention id=1}Alice>

The Pandoc ecosystem established class-driven semantics as a convention (think Quarto's ::: {.callout-note}); DOMD makes it a first-class, declarative API. Types nobody registered don't error — they degrade gracefully into plain CSS hooks.

3. Variants can render as React components.
This is where it stops being styling and starts being product. A variant can bind a React component: the editor hands it the parsed params and the children, and the component renders inside the live document — a clickable @mention pill, a comment mark that opens an anchored annotation card. A strict render contract keeps the caret, selection and collaboration machinery safe, while the component itself can do anything React can do.

4. Markdown stays Markdown.
Extensions never break existing documents — links, images, autolinks and inline HTML keep parsing exactly as before, and new rules only fire where the grammar is deterministically unambiguous. And it's all still plain text: no proprietary file format, ever.

Because DOMD is collaborative at its core, rule sets are part of the peer contract — every collaborator renders the document identically.

Where things stand

• inlineRules v2 ships in @do-md/core-react 0.6 and already powers the app's ==highlight== rule.
• A dedicated playground page is on the way to showcase the full range — mentions, comments, wikilinks and more — while the main editor stays deliberately lean.

Credit where it's due

This API traces directly back to #13 by @paul-hammant. What began as a licensing question turned into the most valuable feature request this project has received: a concrete attempt to port kotaindah55/extended-markdown-syntax (^sup^, ~sub~, =={color}text==), blocked only by the lack of an inline extension point — and written up precisely enough to design against. inlineRules v1 (0.5) was built to unblock exactly that; v2 generalizes it into what you see above. Thank you, Paul — and thanks to kotaindah55 for the original plugin that started the chain. The tinted highlight in the example above is, fittingly, Paul's own =={red}your text==.

Issue #13 is proof of what a good request can turn into — so, what would you build? Syntax ideas welcome in Ideas.