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