Titus

Implementation details should indeed be in the appendix, agreed, but what my issue is more about, is that there’s nothing in the spec arguing for, taking a maybe more clear...

I can’t see an easy solution. One way would be to use “interrupting content” instead of “interrupting paragraphs”: > An indented code block cannot interrupt ~~a paragraph~~ *a content line*....

Yeah, maybe that’s good! I’m not so sure about the word paragraph, as setext headings are made from that construct, but as they are headings, they aren‘t really paragraphs

Another point of confusion for me, I don‘t understand the interplay between paragraphs/setext headings/definitions: E.g.,: ```markdown [a]: b content? a = content? ``` Yields: [a]: b content? a = content?...

The link from markdown still works though, right? You can open both and they go to the same place. Sounds like an issue in pa11y to me

@jgm I believe the idea of leaving that to compilers/generators/implementations is not in the spec, it would be very useful in my opinion to have that documented

My *that* was a reference to your earlier comment (“The spec is really concerned with parsing, not rendering. It's a bit awkward that we use HTML for the examples/tests, for...

Sorry. I think this looks goods! 👍

Here’s what I did for [opening](https://github.com/syntax-tree/hast-util-to-html/blob/master/lib/omission/opening.js) and [closing](https://github.com/syntax-tree/hast-util-to-html/blob/master/lib/omission/closing.js) tags.

This issue was from when I started working on GHs highlighting, which in the end turned into its own project that inlines some of the stuff that `shiki` does, and...