12 ms·
RFC 7764 – Guidance on Markdown
- MBCook 10y agoDid 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.
- jrochkind1 10y agoHe generally hasn't been interested in any kind of standardization, of which this is an example, no?
- MBCook 10y agoTo 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.
- Karunamon 10y agoI 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.
- MBCook 10y agoRight. 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.
- tbert 10y agoI 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.
- MBCook 10y agoI 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.
- gsnedders 10y 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.
- gsnedders 10y agoTo 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.
- zeveb 10y agoI 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.
- Ajedi32 10y agoThis. 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.
- hallman76 10y agoGruber 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.
- jessaustin 10y agoYou 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.
- Ajedi32 10y ago> 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%60%60%0Acode+here%0A%60%60%60 http://johnmacfarlane.net/babelmark2/?normalize=1&text=%60%6...
- numbsafari 10y agoI think Kubrick quote near the beginning is an... homage.
- anamoulous 10y agoI groaned.
- nicky0 10y agoIt's the same quote Gruber himself used here: http://daringfireball.net/2004/03/dive_into_markdown http://daringfireball.net/2004/03/dive_into_markdown The title of the section, Dive into Markdown, is the same too.
- slezyr 10y ago``` function test() { return "notice this feature?"); } ``` Ummm...
- verandaguy 10y agoI'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!
- ausjke 10y agoCan'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.
- doublerebel 10y agoI'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.
- verandaguy 10y agoI 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.
- austincheney 10y agohttps://github.com/prettydiff/biddle 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.
- glaberficken 10y agoAmateur question: Why can´t browsers just fetch a markdown file and render its html representation? (is this what the article implies?)
- dom0 10y agoBecause there are dozens of more or less incompatible markdown dialects.
- verandaguy 10y agoBrowsers 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.
- Ajedi32 10y agoCouldn'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.
- verandaguy 10y agoCommunity 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.
- jalfresi 10y agoDon't markdown files already have a MIME type of text/plain? Isn't that the point of markdown?
- deckar01 10y agoIn 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.
- Freak_NL 10y agoWhat 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.
- kbenson 10y agoI 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.
- chriswarbo 10y ago> 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?
- dTal 10y agoPresumably, 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.
- xer0x 10y agoOMG wow! This could be really helpful!
- nicky0 10y ago> 1. Dive into Markdown Is that an obscure Mark Pilgrim reference or just a coincidence?
- jschulenklopper 10y agoMore than a coincidence, I think. John Gruber wrote a post titled "Dive into Markdown", https://daringfireball.net/2004/03/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?
- nicky0 10y agoAlso, at the time, Mark Pilgrim had a blog called "Dive into Mark".
- smartmic 10y agoI 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.
- inlineint 10y agoI'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.
- mrottenkolber 10y agoThe 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?
- jgord 10y agoNooo.. 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.
- stewbrew 10y agoMarkdown 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.
- kevin_thibedeau 10y agoMeanwhile Restructured Text chugs along with a more capable syntax designed for extensibility from the start and without the problematic fragmentation of dialects.
- c-smile 10y ago"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 http://blocknote.net - WYSIWYG HTML editor that uses internal flat model.