a case for native bounding asterisk support

Allan Odgaard 1edf4d33-d1b1-4c97-a393-3d2b4ee5e095+markdown at uuid-mail.com
Wed Jun 3 22:47:28 EDT 2020


On 4 Jun 2020, at 9:22, Christian Perry wrote:

> It wouldn't have to break anything to update MD syntax: simply present 
> it
> as a new version, and note that certain conventions from old version 
> are
> being deprecated. Put it on LTS and give the industry 15 years to 
> adapt
> (I'm serious about this).

There is no authoritative standard that people follow when it comes to 
implementing markdown.

The closet thing is CommonMark: https://commonmark.org/

I suggest you read their “Why is CommonMark needed?”.

In short, it mentions how there were/are many diverging implementations 
of markdown, and they are trying to make one universal standard, they 
have been at it for five years, and yet we still do not have a standard 
that all implementations conform to.

And now you want to make a v1.1 of this non-existing standard that will 
be incompatible with every document out there?

I get that you are passionate about this, but you are approaching it in 
the wrong way.

You cannot centrally redefine how markdown should be interpreted, that 
is just not possible because none of the tens of thousands of people who 
have written markdown inspired parsers listen to a central body for how 
they should interpret/render text.

If you have a problem with the inability to use asterisks in Slack or 
similar, you need to contact the developers of that software and explain 
that there must be a way to opt out of automatically interpreting 
asterisks as emphasized.

Even if you did manage to get Gruber to update his website to say 
emphasized should be done with double-bangs, Slack would *not* change 
anything.


More information about the Markdown-Discuss mailing list