One thing I'll add, if that's alright, when it comes to transitioning standards. 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). Companies who want v1.1, with native bounding asterisk support, can transition sooner if they want. On Wed, Jun 3, 2020 at 7:07 PM Christian Perry <christian at christianperry.dev> wrote:> Well what *else* could it mean, whether it's true in one's groups or not? > > On Wed, Jun 3, 2020 at 7:05 PM Max Harmony <maxh at maxh.me.uk> wrote: > >> >> >> > On 03 Jun 2020, at 21.55, Christian Perry <christian at christianperry.dev> >> wrote: >> > >> > And when we're talking about UGC in particular, the other uses of >> bounding asterisks are much, much, much more common than the urge to >> emphasize -- yet they depend upon the asterisks being displayed as-is. >> >> While that may be true *within your groups*, I don't think it's accurate >> *universally*. >> _______________________________________________ >> Markdown-Discuss mailing list >> Markdown-Discuss at six.pairlist.net >> https://pairlist6.pair.net/mailman/listinfo/markdown-discuss >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://pairlist6.pair.net/pipermail/markdown-discuss/attachments/20200603/88699595/attachment.html>
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.
Just to throw in another voice saying this is never going to work: people talk as if these things are centuries old traditions but they're not. When people used typewriters, they underlined to mean bold; asterisks have been used in a number of ways since the invention and no one has ever had the power to dictate how things should be. I was using*to imply emphasis or a change of register long before markdown came along. Using italics is a way of changing the register of the text, and you still have to interpret that within the context of the genre you are writing in. in poetry it means one thing, in academic texts another and so on. Better to explain what they mean in your particular context as and when it arises than to try to move the whole world an inch to the left. I'm struggling to understand why people can't escape asterisks like \*this\* if they want them to be visible (it will be interesting to see if my markdown emailer passes that on safely to you all! On 4 Jun 2020, at 3:22, Christian Perry wrote:> One thing I'll add, if that's alright, when it comes to transitioning > standards. > > > > 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). > > > > Companies who want v1.1, with native bounding asterisk support, can > transition sooner if they want.Cheers, Jason