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.
Reference links
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[1] 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.
Raw HTML
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.
Attributes
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.
To keep shortcut reference links readable, how about double brackets?
In other words, links would use external brackets for a reference label [foo][bar], and nested brackets if the link text is its own label [[foo]].
That makes it immediately clear there’s a link, not just a span or literal brackets; and it’s more natural-looking than appending empty brackets [foo][].
[[foo]]
[foo]: https://example.com
<a href="https://example.com">foo</a>
If there’s no link reference definition, the double-bracketed text would still be a link. It could fall back to an implicit page link:
That’s a good suggestion. This is similar to the [[text]] format of the Wiki markup used by MediaWiki, and it is human-readable and doesn’t look horrid.
The trouble would be that it isn’t backward-compatible. But it is something I feel one can support, since I feel standardization is more important than backward-compatibility.
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
Can you share your current thoughts on the state of the 6 items @jgm?
Is there anything specifically we can do to help?
As I say in the document, it’s not really a list of proposals for
modifying commonmark, which has the aim of retaining compatibility.
(Though I have implemented the general attribute syntax as
an extension in may Haskell commonmark library, commonmark-hs,
and it’s available as an extension to commonmark in pandoc.)
I tend to agree the next order of business is to pick the most popular “extension” (as observed in the wild, on the internet) and add that to the CommonMark spec. My vote would strongly be for tables.
That’s assuming we’re confident in the base CommonMark spec and there aren’t any major outstanding, unresolved issues in the base CommonMark spec?
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.