Here’s my vote on the twelve (now eleven!) MUST items, cc: @jgm
Preservation of spaces in backtick code
`are trailing spaces trimmed from here--> `
We should preserve spaces in code spans, unless it’s super hard. There’s a near 50/50 split in babelmark so either approach is really OK.
Backtick fences and inline code collision
``` hello
this is NOT inline code with one backtick ` and two backticks ``;
it is a code block!
```
Multi-word restriction of some kind, or leading space restriction (if possible). Removing code fences is absolutely not an option. Do note that in GitHub code fences the official documentation shows no space between the backticks and the language.
Links within links
[outer [inner](http://inner)](http://outer)
Whatever the simplest way is to disallow this, I think we should do it. As already mentioned by @balpha it feels pathological to me, I don’t see a good use for it.
Inconsistent handling of spaces in links
<http://example.com/hey nice link>
There’s a very well understood way to encode spaces into links, our old pal %20 and spaces in links are some bad mojo anyway that we should not be encouraging. We should not allow spaces in links.
Quotes in titles
Foo [bar](/url/ "Title with "quotes" inside")
Replacing the " with " seems crazily HTML-specific, which long term is not the goal of CommonMark, so I support your solution of allowing the escape \" to work, instead.
URL normalization
Already decided, so great!
Should space be required after # in ATX headers?
#Heading1
I am 100% certain the answer is “yes” here. Way too much damage to average user input if we allow this unnecessary flexibility, largely due to the rise of the #hashtag in popular media. Tighten it down, we have ample proof there’s a problem, and the tension from the fix is minor.
Setext header and list precedence issue
1. Juli
------
- Event 1
- Event 2
I think this should be escaped like any other list special case, or the user can use the ## header form.
Allow setext headers to interrupt paragraphs for consistency
Paragraph
Header
=====
Paragraph
Babelmark says this is quite divergent, and I think we should continue to be strict here and NOT allow sextext headers to interrupt paragraphs, as that reads quite poorly to me in plaintext – what kind of heading has no whitespace?
I don’t find multiline headers particularly compelling.
Odd reference link/list case
- [foo]: bar
baz
Babelmark says a list with one item is what this should produce. Given that there’s virtually no divergence here, do we care? Are people really running into this? Is it a useful set of input?
Remove two-blanks rule
I’ve come to think that the “two blank lines breaks out of lists” rule is more trouble than it’s worth…
… I think the current spec could be clarified if rule 1 for list items explicitly said “a sequence of lines not containing two consecutive blank lines that are not in a fenced code block.”
I completely trust your instincts on this one. Everyone in the topic says your suggestions are reasonable, so go with whatever you believe is best here.
Handling of tabs needs to be further specified
>[TAB][TAB]x
Seems to me a tab is not quite a space, so the “is this a space after a blockquote” rule doesn’t apply.
I think the babelmark results show a rough consensus that this should be a code block with 3 spaces.
Honestly I think as long as a code block is rendered, which is definitely the consensus here, no one will be too bothered by some extra spaces.
Entity handling
Revise what the spec requires a propos entities:
See Spec Issues: (Character) Entity References - #12 by tin-pot
Entities · Issue #442 · commonmark/commonmark-spec · GitHub