I think @aoudad’s suggestions on emphasis are sound, keeping both ease of reading and backward compatibility. On the rest, I tend to agree with @jgm. However, the bit that I find toughest to get behind is getting rid of shortcut reference links. Those are not only convenient, but are very readable as well. [foo] gives up a bit of that human-readability for parsing convenience.
I like using _emphasis_ and *strong emphasis*. As somebody mentioned already, that’s how it works on WhatsApp, Facebook, and Slack, and it seems very logical. They also support ~strikethrough~, `monospaced`, and triple-backtick code blocks, which are all nice.
I personally don’t care much for intra-word emphasis and I’d rather keep the single tilde free for strikethrough syntax.
Shortcut reference links are great, and it would be a shame to remove them. They are very intuitive and readable. Just go to a random Hacker News comment thread and you’ll see people instinctively using them, even though they’re not supported there (just Ctrl/Cmd+F to see examples).
They are also essential for wiki-style and academic writing, which are both extremely rich in references. The extra noise caused by [this style] would hurt readability.
Indented code blocks
Big yes to the more logical list indentation style, and to removing indented code blocks. What a pain they are.
Not a fan of the specific syntax (why the extra =?), but this sounds good in general.
Lists and blank lines
I’d rather we just allow the creation of a list even without a blank line separating it from a paragraph. It seems to me this would rarely be a problem in practice. The example given can just be fixed by having 220. be on the previous line. Or maybe one could allow escaping the period like so 200\. to mean that you really do want to write 200. at the beginning of the line, and not start a list. Again, I really doubt this will happen very often.
Why not use a consistent way of creating attributes for headers, like on GitHub? This would avoid having to introduce extra syntax, and keep documents cleaner.
I would say MediaWiki is exactly the reason why IMHO Markdown (or derivatives of it) should not use [[foo]] for the ordinary links. Wiki is one very natural application for Markdown-like syntax and it’s therefore better to reserve that syntax for wiki-links to other articles defined by the database of its articles; not to some arbitrary URIs.
Is there sufficient consensus to move forward on any of the 6 items that @jgm flagged? Given that commonmark is yet to have a 1.0 release, I feel some simplification and rationalization would still be a good idea. Given a tool like pandoc exists, people could convert from non-compliant markdown formats into commonmark-compliant format quite easily, and it is a one-time process. Hence, backward-compatibility should be a hard-block, in my opinion.
All things considered, I still stand by this assessment that I posted 1.5 years back: Beyond Markdown
The discussion around creating a new language is interesting, but a bit of a distraction from the goal of strongly specifying Markdown. Unless there’s some consensus about moving applications to the new language, there’s probably more practical value in formalising what’s already in wide use. I agree with @codinghorror about moving forward with extensions; assuming that it is relatively stable, could the core spec be left in a pre-1.0 state for the time being and extension specs built on top of this?
But even for simple pipe tables there are a number of tricky
cases to consider, and if you want to open up more features
(row/colspans, side headings, headers and footers, etc.),
it starts to get very complex very fast.
For now I’d suggest that anyone who is adding a table extension
should make it compatible with the gfm table spec.
It would be very useful if your implement one comment character (or a double comment character) that have the function of making all the line following it as a comment, and thus ignored in displaying the text.