RFC 7764 – Guidance on Markdown | Hacker News Reader

RFC 7764 – Guidance on Markdown

tools.ietf.org

181 pointsarthur2e5109 comments

What I would really like is to end up in a situation where email clients all support text/markdown. It really hits the sweet spot between plain text and HTML. It has enough structure to show a nice outline, and the triple back-tick syntax is great for marking bits of text as code.

All without specifying how everything should look. You can read it as unformatted text, or let the mail client format everything in a style you like. This is sort-of like HTML without CSS (using the client's default stylesheet), but also very well readable as unformatted text, and free from the abuse of HTML email.

Alas. More and more companies are giving up on plain text email (even though this is required by the standard), and simply send you a hyperlink to click if you have plain text as your viewing preference for email.

I think all it would take is Gmail adopting it to start a chain reaction, and Gmail adoption actually seems somewhat plausible to me. Google has a habit of implementing things aimed a bit more at power users (while also omitting things that a a bit more middle-of-the-road). I could totally see some internal project that does this for Gmail making it to the public.

> What I would really like is to end up in a situation where email clients all support text/markdown.

I don't understand; markdown is text. If you send markdown emails right now, what's the problem?

Admittedly I might be biased, since I read mail as plain text in Emacs, but surely plain text emails will display in all mail clients?

Presumably, a Markdown-enabled email client would display a pretty-printed version of an email it thinks is in Markdown. The output, not the input.

Markdown is no more text than HTML is. Which is to say, it is, but it also has more structure you can teach software to interpret intelligently. The only difference is that Markdown is 1) more human readable and 2) less standardised.

I think reifying our social conventions for conveying formatting over plaintext so that software can understand it is an excellent initiative.

> If you send markdown emails right now, what's the problem?

If you structure plain text emails with MarkDown nothing is wrong per se, but if clients can also highlight (in a text editor like plain text view) or format (in a HTML like view), than there is significant added value for a lot of users, without the downsides of HTML email.

> What I would really like is to end up in a situation where email clients all support text/markdown. It really hits the sweet spot between plain text and HTML. It has enough structure to show a nice outline, and the triple back-tick syntax is great for marking bits of text as code.

Then we would have come full circle. A markup language that has been at least inspired if not derived from decade old usenet/mail conventions would be back where it started from.

> [...] and free from the abuse of HTML email.

Are you sure? The advantage of text/plain in mail is that I see every link as it is and no resources are loaded from external sources.

With markdown support in mail clients, we might be back at early HTML support. Link destinations would be unknowable again.

> Alas. More and more companies are giving up on plain text email (even though this is required by the standard),

If it's not plain text, it has to declare a mime type (how would the mail client know how to render it?) but I don't think plain text section is mandatory.

> and simply send you a hyperlink to click if you have plain text as your viewing preference for email.

Go tell them, and you can quote me on that, that they are stupid. If my mail client doesn't render text/html and prefers the text/plain sections that is because it is configured that way.

I know of no mail client that isn't able to handle HTML.

mail. mailx. elm. pine. mh. nmh.

You're welcome.

I said "handle". Especially Unix programs almost always have a way of going beyond a programs limitations.

Elm and pine support mailcap files. IIRC (n)mh does as well via mimeview (or is that only the GNU version?). But a program where scripting is a part of its core design, there will certainly be ways of calling an external program for converting HTML to be viewed.

Mail and mailx, do they even support mime types? AFAIK they don't but then you just need to set up PAGER with an intelligent enough program I guess.

Now if you said telnet or netcat, I would truly have been at a loss.

telnet and netcat aren't MUAs, they are just useful tools. If you say netcat, I have to say libpcap, and then where are we, huh?

Also, mail/mailx don't use PAGER for 'print', although I just learned you can use 'more' to invoke it.

> Then we would have come full circle. A markup language that has been at least inspired if not derived from decade old usenet/mail conventions would be back where it started from.

Is this a bad thing?

> Are you sure? The advantage of text/plain in mail is that I see every link as it is and no resources are loaded from external sources. > With markdown support in mail clients, we might be back at early HTML support. Link destinations would be unknowable again.

Not seeing how link destinations become unknowable. With no scripting there's no way for a site to hide the destination, it is what it is. Your viewer can choose to display it however it wants. Status bar like a browser, tooltip, whatever.

> If it's not plain text, it has to declare a mime type (how would the mail client know how to render it?) but I don't think plain text section is mandatory.

It is though. That's a major advantage of Markdown, by adopting those well-established mail/usenet conventions where practical and attempting to follow that sort of principle with less defined formatting there's not really anything lost if you treat it as plain text. The other way around is almost as safe, with very little chance of a a plain text message treated as Markdown being misinterpreted in a way which significantly impacts its meaning.

> I know of no mail client that isn't able to handle HTML.

Any text-mode mail client? I mean sure there are some that can interpret basic HTML formatting and translate that to control characters for a sufficiently capable terminal, but modern HTML mail tends to go far beyond that. Basically what formatting a text-mode client can actually handle also happens to be the same formatting that Markdown supports. No images, no fonts, no colors, just paragraphs, links, quotes, and some basic emphasis formatting.

>> Then we would have come full circle. A markup language that has been at least inspired if not derived from decade old usenet/mail conventions would be back where it started from.

> Is this a bad thing?

Not a bad thing but in this case it seems a little bit pointless as we wouldn't have gained much.

It happens a lot that something that is popular now has been there a while ago so you have some old farts saying "but we already had that 20 years ago!" although often there are some crucial changes to how it looked then so that it now has a completely different impact.

For example, we are about to get WebAssembly in the browers, essentially a bytecode VM. We had that 20 years ago with Java, although the integration of Java and the browser was not tight enough. Or VR which 20 years ago was quite hyped and then somehow just died down and for all I know the difference to today is only that the graphics was crappier back then.

Markdown in the mail client doesn't give you much over what we had 20 years ago. If I enable format-flowed and use a variable-width font, it probably looks quite similar to the rendered Markdown.

Oh, one thing I forgot about unstyled HTML pages. Mobile browsers suck a rendering that.

>> I know of no mail client that isn't able to handle HTML.

> Any text-mode mail client? I mean sure there are some that can interpret basic HTML formatting and translate that to control characters for a sufficiently capable terminal, but modern HTML mail tends to go far beyond that. Basically what formatting a text-mode client can actually handle also happens to be the same formatting that Markdown supports. No images, no fonts, no colors, just paragraphs, links, quotes, and some basic emphasis formatting.

Any text-mode mail client will have ways of rendering HTML with the help of external programs. That's not surprising, as they already needed that for things like images or PDFs. Some even let you fire up a browser to read them, some have some basic HTML parsing capabilities but I think most just do let some program convert the HTML to text to display inline as if it were a text/plain section.

As you can't rely on scripting being enabled (are there actually any mail client that still have HTML scripting?) the HTML needs to have all the text you want the receiver to read, so converting it to text usually works fine. I can't remember reading any legit HTML mail in the last years where this wasn't the case.

For transactional email I like liquid templated markdown. We render each through liquid, then send the resulting markdown in the text/plain part, and render it with redcarpet and github's sanitizer for the text/html part.

We used to downsample from HTML to plaintext with many irksome artefacts arising. These look a lot better. It does oblige a certain discipline on the part of template writers, I consider that a good thing.

Have you tried Markdown Here ? http://markdown-here.com/

I use it on almost every email. It is really great.

That's just a hack though it just generates html based on the markdown you type.

It for example won't help me with reading emails in console :/

BTW: Things like this makes me wonder if I'm the only one who still uses MTA.

If there was a defined standard text/markdown the emails would simply be sent in markdown which could be nicely rendered in GUI, be readable in plain text and also safe unlike html.

I'm actually kind of excited about this! A `text/markdown` MIME type could (maybe? hopefully?) pave the way for native content authoring in Markdown without having to use an HTML-targeting compiler between the author and the browser.

I might be being optimistic, but if that ever happens, it could be the start of a new era in internet content authorship!

Can't agree with more. It's a pity these days, for nearly all the WIKIs, CMSes, blog platforms, still markdown is not the native format supported out of the box, most of them needs plugins etc, or you need run a static-site-generator to convert markdown to HTMLs.

I've long thought that YAML instead of JSON and Markdown instead of HTML would be ideal for the average person to get into internet content production and sharing. Combining both specs is YAML Front Matter, where metadata can live with the document.

Sure, the YAML and Markdown specs could be more strict but right now browsers are very tolerant of malformed HTML.

Unlike HTML it would help separate data/content from presentation, which I think is at the root of ads and poor quality content we are forced to sift through now.

I don't have any strong opinion about YAML (or YAML Front Matter), having never used it much, but at a glance it seems reasonable to focus on writing content in.

On a sidenote:

    Sure, the YAML and Markdown specs could be more strict but right now browsers are very tolerant of malformed HTML.

This wouldn't be possible without an extremely well-defined HTML spec :) For example, if I write the following in a hypothetical browser-parsed Markdown document:

     _Hello!_
     *Hello!*
     **Hello!**

Which one should show up as bold? What about italic? Which one should just be surrounded by {1,2} asterisks?

Conversely, if I have:

     <ul>
         <li>Hello</li>
         <li>World!
     </ul>

Many browsers can determine (non-trivially, and not always, granted) that there's an unclosed `<li>` tag inside a closed `<ul>` environment and work with that. It's generally a different class of problems, though.

(non-trivially, and not always, granted)

Note that <li> example is perfectly valid, and will be parsed correctly by any html5 capable parser. Per the html5 spec, the closing tag on an <li> element is optional.[0]

[0] - https://html.spec.whatwg.org/#optional-tags

An li element's end tag may be omitted if the li element is immediately followed by another li element or if there is no more content in the parent element.

Fair enough, TIL. I'd imagine it's much less valid if the missing closing `</li>` is on the first line, though.

No, you can write the entire list without any </li> tags and it's perfectly fine. You also generally don't need to close your <p> tags to start a new paragraph, because paragraphs don't nest inside each other.

This is a perfectly valid html5 document:

  <!doctype html>
  <title></title>
  <ul>
    <li>item1
    <li>item2
  </ul>

First two lines are italic, last one is bold. I'm not sure the point you are making, as all three are straightforward examples of unambiguous Markdown. (There are plenty of ambiguous cases you could have picked...)

IIRC Slack does bold with single asterisks.

But slack doesn't claim to use Markdown.

> Though we understand many people would love to use Markdown in Slack messages, we have no plans to support it. Our message formatting is similar to other popular services like Skype and Google Talk, and is intended for a majority of our users who are unfamiliar with Markdown. However, we'll keep it in mind for the future.

https://get.slack.help/hc/en-us/articles/202288908-Format-yo...

> Which one should show up as bold? What about italic?

Markdown has no notion of italic and bold styling, only semantics for emphasis and strong emphasis.

YAML has the problem that it has a lot of well-defined but incredibly unintuitive behavior.

    // this is a string
    quote: I say, good man, could you spare a vowel?

    // this is a parsing error
    quote: And then I said: "Oh, god, man, you're an aardvark!"

    // this is a string (not including the quotes as part of the string)
    quote: "And then Winston Churchill kicked him square in the knee."

    // this is a string (including the quotes as part of the string)
    quote: |
      "What do you mean, all the monkeys have escaped?"

    // this is a string
    theCharacterToShow: =

    // this is a null value
    theCharacterToShow: ~

    // this is a boolean true
    theCharacterToShow: y

    // this is an integer
    obscureAnimeTitle: 0xDEADBEEF

Which markdown? There are various variants out there and the original is unsuitable for more than a most basic web page.

The RFC for text/markdown includes a variant specifier but that only makes me think that we would be repeating the mistake of early browers when there were browser-specific HTML tags.

    Which markdown?

That depends on which one eventually gets specified (if at all) by some reputable standardization body. And sometimes, people don't want much more than a static web page!

Good point; we'd definitely need a standard. Thankfully, [CommonMark][1] has been in development a while now, and features a complete, unambiguous spec, reference implementation, and test suite.

A little more work on that to get it to version 1.0 and we'd be golden.

[1]: http://commonmark.org/

Is it really unambiguous? There is no grammar, but the spec describes things in English. It's really hard to avoid ambiguities and impossible to proof unambiguousness without formal methods.

I guess it's hard to say for sure that it's completely unambiguous, but that's definitely the intent. [The spec][1] even says:

> This document attempts to specify Markdown syntax unambiguously.

So if you're aware of any ambiguities in the spec, those are bugs which should be reported and fixed.

[1]: http://spec.commonmark.org/0.27/

You may want to work on specifying a formal grammar in EBNF or similiar.

Great for library / parser implementers and it helps discover ambiguities.

From John MacFarlane, the author of the CommonMark spec:

> If anyone wants to contribute a BNF, please do! But I'm very skeptical that it can be done, due to the many quirks of the syntax.

https://github.com/jgm/CommonMark/issues/113#issuecomment-60...

So it's basically as useless for general processing as Markdown, because you won't have a grammar from which you can generate parser, hence all the parsers will be handcoded with various quirks differing from one to another and none of which will produce a parse tree.

If it's hard to write a BNF, it's also hard to write a parser.

I'm baffled. Without a formal grammar CommonMark is useless. Who implements a parser without a formal grammar?

If the syntax has so many issues that you can't specify a formal grammar, there's a problem with the spec.

BNF doesn't make something unambiguous.

I mean, Foo = "hello" / "hello" is totally acceptable, and if you have any indirection like Foo = XXX / YYY with XXX, YYY = "hello" you can then attach different semantics to XXX and YYY despite it being ambiguous. Add in more levels of indirection, and you have a lower chance of it being trivially obvious.

But there exist tools to help you decide wether a grammar is unambiguous when you have a formal grammar: https://en.wikipedia.org/wiki/Ambiguous_grammar#Recognizing_...

http://vfmd.org has an exhaustive and unambiguous formal spec for (a variant of) Markdown. As a bonus, it's easy to understand, nicely extensible, and has an example implementation. The only drawback I'm aware of is that it seems routinely ignored by nearly everyone. I wonder why?

While the spec is way more formal, it's still not in a form that easily lends for a proof that it's unambiguous.

I have not looked into the details of the grammar, but proving that a grammar is unambiguous is typically done by proving that it is in, say, LL(1) or LR(1) (or some related family). This approach towards unambiguity has the additional advantage that it is easy to derive a parsing algporithm directly from the grammar that has nice theoretical properties (e.g. linear parsing time in the input length; where the hidden constant depends on the grammar).

There is no grammar, it's a description how to parse markdown using regexes.

What a great idea. This is exactly what we need.

I wonder if Markdown will ever get style annotations? Like CSS, but lighter and less broken.

What kind of style annotations? Markdown can already do bold, italic, and in some implementations, ~~strikethrough~~ and ^superscript.

Anything much more complicated than that I think risks jeopardizing Markdown's readability in plain text format and intuitive simplicity. Markdown is meant to be focused more on content than style.

I think XHTML shows that trying to create the specification first puts the cart before the horse.

Write software first; people will create content that matches the platforms that they care about most.

I wonder why VFMD (http://vfmd.org) isn't the choice among people picking a Markdown specification or parser? Well specified, unambiguous, easily extensible, with a reference implementation, open-source. I'd imagine it could be at least mentioned in the RFC?

Extremely interesting backstory from when Standard Markdown was announced: https://news.ycombinator.com/item?id=8264733

Basically a small group of people worked in private for years while there were public community efforts, including a W3C gorup, to do the same. None of the disparate efforts coalesced into a unified front, so the simple answer is that projects advocated for whatever spec their developers backed. The community is fractured.

Does it matter? If your email client doesn't understand enough of the markdown variant being used, then you should still be able to read the unrendered text. That's one of the great things about markdown.

Are you aware of https://ia.net/writer ? It is a markdown text-editor for MacOS & iOS that many people seem to enjoy.

The best decision would be to drop Markdown from everything and pretend it never existed. Then design a similar format with a formal grammar, and use that.

The sad thing is this won't happen. Given the traction I suspect there will be broken, incompatible Markdown implementations 100 years from now. Markdown really has the potential to become the worst universally popular standard in computing history.

What bothers me is that its not one guy (Gruber) who made a mistake and designed a language without a formal grammar (hey, mistakes happen), its that armies of developers wrote broken parsers for a language without a formal grammar. This is an impossible task, why did they not refuse to create something fundamentally broken, by definition. Now there are apparently people who want to standardize Markdown, without a formal grammar. How can they not realize that it will be impossible to ever implement the standard? How do they not see that what they are doing is professionally unethical?

Nooo.. it just needs a proper formal grammar adopted, that captures the best of the common variants.

Then people can extend their tools to use that single variant and standard parser/grammar.

Most [good] languages were implemented first without a formal grammar - lex/yacc/bnf usually came later, if at all.

Markdown is quirk mode plain text. That was probably ok for its original purpose but it is not for what it is used nowadays. There are much better plain text like formats around and it's a shame markdown is in the position it is now. IMHO a well-defined subset of LaTeX (or context) with almost plain text markup for the 10 most commonly used commands would have been the better solution on the long run.

Don't markdown files already have a MIME type of text/plain? Isn't that the point of markdown?

In the context of emails, I don't believe using a special MIME type for markdown provides any benefit. Raw markdown is plain text and generated content is HTML.

It seems interesting in the context of version controlled markdown files written for a particular hosting platform's markdown flavor, but I don't think a specification for identifying the flavor is the solution. This could be no different than any other form of documentation that is generated by a script or framework, but code hosting platforms have decided to make opinionated decisions for a magical UX.

I'm not sure wouldn't someone say that it is bloating of such simple format as Markdown, but I really want to see embedding of TeX math formulas in Markdown RFC/standard.

I'm talking about $\frac 3 4$ and $$\int x dx$$ notation. It is already implemented in some Markdown parsers, such as Pandoc and Jupyter Notebook, but because it is not standardized there are also a lot of parsers that don't support it. I think that adding it to the RFC/standard would reduce friction in math communications and make them more accessible, especially if Markdown format become widely used for email communications.

"Oh how many of them had fallen into that chasm..." (C) M. Tsvetaeva

Instead of markdown we need something what I name as flat structural text format.

     <text>Base level text</text>
     <text li="disk">Bulleted list item</text>
     <text li="numeric">Numeric list item</text>
     <text li="numeric" level=2>Another list item</text>
     ...
     <text>Inline <span bold>bold</span><span bold italic>bold and italic</span></text>   
     ...

In this case it will be trivial[1] to write WYSIWYG editor that has 1:1 mapping between markup and screen representation.

That 1:1 mapping is mission critical for human editing - our mental model of text is flat.

In fact that markdown is an attempt to provide such flat structural text representation. Ugly one we shall admit.

Microsoft Word, AFAIU, uses also flat DOM model internally, that's why its WYSIWYG is quite good.

HTML version 2 was last version that allowed unambiguous WYSIWYG editing of HTML. The one that had no idea of CSS.

[1] http://blocknote.net - WYSIWYG HTML editor that uses internal flat model.

This entirely misses the point of Markdown: that it's completely readable as a document without needing to apply any kind of visual formatting to it.

> completely readable ...

That's very subjective and only in very simple cases. Like "markdown" version here, on HN.

> 1. Dive into Markdown

Is that an obscure Mark Pilgrim reference or just a coincidence?

More than a coincidence, I think.

John Gruber wrote a post titled "Dive into Markdown", https://daringfireball.net/2004/03/dive_into_markdown, and mentioned Mark Pilgrim in that post as well. It seems that John made a pun, applying the well-known titles of Mark's books to Markdown.

I guess the RFC copies the post title (and the opening quote by Stanley Kubrick) to pay an homage to John's start with Markdown?

Also, at the time, Mark Pilgrim had a blog called "Dive into Mark".

Meanwhile Restructured Text chugs along with a more capable syntax designed for extensibility from the start and without the problematic fragmentation of dialects.

https://github.com/prettydiff/biddle Can parse markdown to formatted stdout (ANSI colors, wordwrap, and so forth) on the console in both posix and Windows.

I am still struggling with Markdown. In my opinion, the lack of a common, standardized specification thwarts its practicability as universal internet standard.

I still wonder why not more powerful markup languages like asciidoc spread more.

Amateur question: Why can´t browsers just fetch a markdown file and render its html representation? (is this what the article implies?)

Because there are dozens of more or less incompatible markdown dialects.

Browsers implement well-defined web standards, which Markdown unfortunately isn't. The original author, John Gruber (of daringfireball.net), hasn't been too supportive of having a single, fixed Markdown standard, and this has resulted in spinoffs with various syntaxes and features:

- GitHub-flavoured Markdown

- CommonMark

- etc...

On top of that, there isn't even some meta-standard which would allow hashbang-style preambles/doctype declarations to determine which version of Markdown is being served.

So, between the fact that there's no fixed de-facto standard and no de jure standard syntax or feature set recognized by any of the major standards bodies (IETF being one of these), it would be impractical for browser vendors to implement support for Markdown.

Finally, the standards that browsers implement take time both while being defined, as well as while being implemented; these are things that will be seen by billions of people worldwide, and there's extremely little room for error, so revisions are always necessary at every stage in development. For example, work on HTML5 can be traced back as far as 2004, meaning that from inception to release, development took about a decade.

Couldn't they just adopt CommonMark? That flavor already has a complete spec and test suite, and is specifically designed to be as compatible with existing implementations as possible. I believe the only thing really missing is for more of the community to start rallying around the standard.

Community engagement's a big part of it, though. I can define my own, extremely thorough and well-documented standard for Markdown, and get, say, all my friends to use it and provide feedback; that wouldn't make it popular enough to be included in a browser.

CommonMark has not published a formal grammar.

> For example, work on HTML5 can be traced back as far as 2004, meaning that from inception to release, development took about a decade.

For some more specific reference points:

Web Applications 1.0, as it was then, first defined the parser some time between February 2006. It first shipped in a browser (as the normal HTML parser) in Chrome 7 in October 2010. The parser was in the latest release of every major browser with IE10 shipping in September 2012. In a sense, therefore, when it came to parsing it took under seven years.

> Browsers implement well-defined web standards, which Markdown unfortunately isn't.

What? All of today's browsers can trace life back to before standards existed and they are constantly adding experimental, non-standard functionality.

OMG wow! This could be really helpful!

  ```
  function test() {
    return "notice this feature?");
  }
  ```

Ummm...

Did anyone ask Gruber for his help in this? Or is this like the stupid attempt at 'common markdown' a year or so ago to wrest 'control' out of his hands because he was 'a terrible steward' (or whatever the quote was).

If a single guy invented the standard, and you're not involving him (or at least getting his blessing), then this seems hostile.

I haven't seen him mention this on Twitter, which is what makes me wonder.

He generally hasn't been interested in any kind of standardization, of which this is an example, no?

To my knowledge, you're right. That's why I was simply trying to ask if anyone knew if he was involved. I wasn't expecting it to turn into a huge discussion.

I was simply curious.

I had a quick skim.. it appears this isn't what you'd think is a "markdown RFC", it's more like a list of different implementations with links to each. Most critically, it is not an attempt to standardize a specific dialect, or wrest control away from its creator.

My bureaucracy detector redlined the moment I clicked through, but then reset after a page or two.

Right. I noticed it's a true "This is how it's done", it's more of a "this is how people tend to treat things". It's descriptive not prescriptive.

After the standard markdown/common markdown kerfuffle I may simply be on high alert, and worried that this is step 1 towards problems.

I assume you didn't open the link. I appears to be a summary of the type of data you can expect when reading a text/markdown document. It does not define a standard, but it lists contact info for many of the different implementations.

I opened the link. I saw what it was doing, but I still wondered if he had been involved, I didn't see any indication either way.

Perhaps would have been willing to lend his name to something that was just a more formal definition of what he's already created (without the additional stuff that other implementations choose to addd).

Again, trying to define someone else's work when they're available without their support/cooperation seems very hostile to me.

I doubt I would have felt this way if we didn't have the attempted coup of "standard markdown" a few years ago.

> Perhaps would have been willing to lend his name to something that was just a more formal definition of what he's already created (without the additional stuff that other implementations choose to add).

I would assume he wouldn't have been, because "ambiguity is a feature". He has explicitly spoken against any attempt to produce a clear specification of Markdown, so it seems highly unlikely.

To reply to myself:

I feel like it's not dissimilar to what happened with HTML. Mozilla and Opera tried to get the W3C to write a better spec and iterate on HTML in 2004, and the W3C membership voted against it… they then, with Apple, started their own organisation (the WHATWG) which wrote their own spec called "Web Applications 1.0" which was essentially a new HTML spec.

I don't think Common Markdown was a stupid attempt; I thought it was a praiseworthy attempt to standardise places where differing Markdown implementations differ, needlessly harming interoperability.

I think that Gruber deserves a colossal amount of credit for inventing the single-most-common end-user-usable marked-up-text format around. That's independent of what he's done in the dozen years since December 2004, which is the last update he made to his Markdown project's page.

Gruber gets credit for creating it AND for holding it back. Markdown needs a common standard. Gruber needs to hand Markdown over to folks who will let his legacy shine.

You write "credit for... holding it back" in an ironic sense, but ISTM that's really the only reason that markdown has seen wide adoption while numerous other simple markup languages have not. There haven't been dozens of different doodads grafted on at different times in different fashions to confuse users and converters, so people just use it and it just works.

> There haven't been dozens of different doodads grafted on at different times in different fashions to confuse users and converters

Oh, but there have. For instance, code fences are not part of the original markdown spec, but are commonly supported in just about every implementation out there, and are rendered in about [7 different ways][1] depending on which converter you're using.

Play around for a little in BabelMark and you'll see why a standard is needed.

[1]: http://johnmacfarlane.net/babelmark2/?normalize=1&text=%60%6...

Well that's one doodad, and apparently it has had the effect I predicted. Never mind, go ahead and have fun with your new super-markdown. One rather doubts it will displace actual markdown anytime soon.

That's exactly the problem: there is no "actual Markdown". Just a bunch of mutually incompatible competing implementations.

If something like CommonMark had existed from the beginning, we wouldn't have this issue because everyone would be following the standard.

What is a "code fence"?

It's an alternate way of annotating code blocks which doesn't require you to indent every line (because that can be tedious for longer code snippets), and allows you to explicitly specify the language to use for syntax highlighting.

Example:

```javascript

// JavaScript code here

```

It's used extensively on GitHub.

Thanks. I've seen that but hadn't connected the name to the syntax.

Except that's not what happened. GitHub-flavoured Markdown was pretty widespread before CommonMark arrived.

Also the problem with his "original specification" is that there isn't one. There's a description that demonstrates the basic syntax and a buggy implementation in Perl that isn't being maintained.

Sure, and every time I use such a "custom" feature, I have to look up how it works. If markdown were less static, the whole language might be like that. That's fine for some uses, but not when the use is a simpler, more memorable way to generate html.

If Markdown were less static, you wouldn't have to find random implementation-specific documentation describing custom features - they'd be defined in the spec. You also wouldn't wind up in situations where two different Markdown implementations interpret the same Markdown text in two different ways, which happens surprisingly often.

Markdown text is therefore always written for use with a specific implementation, and can't realistically be used as a text interchange format in e.g. email or any other federated system with multiple rendering implementations.

Markdown is kind of like CSV, where common usage pre-dated both Gruber's script and future attempts at standardization. His co-author Aaron Swartz confirms [1] that Markdown was greatly inspired by (and is largely compatible with) the way people used to 'mark up' plain text in ways that were emergent and natural to them back in the email days. Therefore, the lack of formal syntax is, to them, a feature.

This doesn't prevent forks, of course, but anyone who wants to perpetuate the 'Markdown legacy' should consider this.

[1] http://www.aaronsw.com/weblog/001189

I understand the appeal of basing Markdown's syntax off of the way people naturally tend to structure unformatted text (and in fact, that's one of the reasons I love Markdown so much), but I'm still really confused as to why anyone would regard syntactic ambiguity as a feature.

Leaving any sort of ambiguity in your spec inevitably leads to different implementations resolving those ambiguities in different ways, which confuses users and causes problems with interoperability.

Is there some sort of upside to these syntactic ambiguities that I'm missing which might offset those obvious drawbacks?

This. As far as I'm concerned, CommonMark _is_ the canonical standard for Markdown.

Gruber has contributed nothing to Markdown in over 12 years, and has refused to participate in anyone else's efforts to improve the spec. That's more than enough justification for a fork, and as far as I'm aware there are no other actively maintained Markdown specifications in existence at the moment, so CommonMark _is_ the standard.

It's wasn't a stupid attempt, I think it was jackassery. I can understand the idea of wanting a very clearly defined markdown like thing.

The problem was that it was called Standard Markdown, seeming to imply that it was correct and was done without the creator's consent. It was an attempted hijacking of the name.

After the mess it was renamed Common Markdown which is a much better name and less offensive, but by then it had left a very bad taste in my mouth. Or they could have given it a new name and no one would have been that upset. But the announcement had personal attacks against Gruber (Ajedi32 correctly pointed out I was wrong here) and seemed to imply they were taking over stewardship and that was totally uncalled for.

In what way does the [original announcement][1] include "personal attacks against Gruber"? His name is only mentioned once:

> Because Gruber’s syntax description leaves many aspects of the syntax undetermined

How is that in any way a "personal attack"?

Furthermore, Gruber was given [two separate opportunities to review the name of the project before it was published][2] (which he ignored), and after the spec was published and Gruber did object to the name, one of the developers of the spec [immediately apologised][2] and changed the name to Common Markdown. How is that "jackassery"?

[1]: https://blog.codinghorror.com/standard-flavored-markdown/

[2]: https://blog.codinghorror.com/standard-markdown-is-now-commo...

Seems you're right. I could have sworn there were personal attacks. Guess my memory is faulty. I put a note in my comment to reflect that.

I think it was jackassery to presume the ability to use the name Standard Markdown without affermative consent from Gruber.

They sent two emails and Gruber didn't reply. Maybe he ignored them, maybe they got lost in a torrent. I don't remember what Gruber said on his podcast (if anything, I seem to remember he didn't want to talk about it much).

They took a 'ask for forgiveness' (because we don't like what you are doing/not doing) approach when I think decorum dictates an 'ask for permission' approach. If you don't get it (they didn't) then call it something else. Stack Overflow Markdown, Spolsky-down, Easymark, whatever.

The implication of the term Standard Markdown is clear. WE own it, WE control it, WE'RE in charge. They didn't have permission/authority for that and did it anyway.

I found that a very jackass move. I stopped following Spolsky because I lost respect for him for doing it.

But if you read [the apology][1] I previously linked, you'll see that Jeff Atwood (not Joel Spolsky btw; he is not involved in CommonMark in any way AFAIK) stated that the attitude you're inferring from the name "Standard Markdown" ("WE own it, WE control it, WE'RE in charge.") was never the intent:

> We were simply trying to pick a name that correctly and accurately reflected our goal – to build an unambiguous flavor of Markdown. If the name we chose made inappropriate overtures about Standard Markdown being anything more than a highly specified flavor of Markdown, I apologize. Standard does have certain particular computer science meanings, as in IETF Standard, ECMA Standard. That was not our intent, it was more of an aspirational element of "what if, together, we could eventually..".

You're of course free to dismiss that explanation as insincere, but I think you may be reading some malicious intent into this that simply wasn't there.

[1]: https://blog.codinghorror.com/standard-markdown-is-now-commo...

Crud. Got the name wrong too huh?

I remember the apology, and I understand why the name "standard" appealed to him. It's certainly what he was trying to do and normally would be a great name.

Except someone else was in control of Markdown so calling your project "Standard Markdown" seems rather hostile to me (or at least rather oblivious).

except gruber didn't "invent" it.

he took the idea from dean allen, who developed "textile" in 2002 as "a humane web text generator".

textile was used in movable type, the blogging software that gruber started with on daring fireball.

he gave his system a clever name, which is important for marketing, but gruber did _not_ "invent" it.

in today's lingo, he "rebranded" a great idea from somebody else.

> https://medium.com/the-bower/markdown-considered-harmful-495...

-bowerbird

I think Kubrick quote near the beginning is an... homage.

I groaned.

It's the same quote Gruber himself used here: http://daringfireball.net/2004/03/dive_into_markdown

The title of the section, Dive into Markdown, is the same too.

Reply on news.ycombinator.com