This doesn't really make sense, for a couple reasons...
There are many flavors of markdown. We'd need a standards body, compatibility suites, etc., and for all the browser vendors to adopt it.
Meanwhile, markdown is designed to transform to HTML, which browsers already render. Adding a markdown-to-html plugin/step to your web server or publishing process is not exactly the most burdensome thing, relative to everything else it takes to develop, publish, and maintain a site. And it resolves the markdown flavors issue.
The thing is, people could choose to publish, simple uncomplicated sites now -- it would be cheap and easy, too. The HTML is barely more complicated than the equivalent markdown, and it would take a few lines of CSS to apply a basic style.
The many sites that choose to be complicated, cluttered, and expensive will continue to be so, for the same reasons they are now. Markdown would just be another way to build simple sites, which they don't want.
For people considering adding Markdown support to web browsers or other publishing tools, please consider adopting Djot instead: https://github.com/jgm/djot
It's very similar to the Markdown syntax we all know and love/hate, but fixes many inconsistencies in the spec, and also makes it possible to parse a document in linear time, with no backtracking. It is also much fuller-featured than commonmark, with support for definition lists, footnotes, tables, several new kinds of inline formatting (insert, delete, highlight, superscript, subscript), math, smart punctuation, attributes that can be applied to any element, and generic containers for block-level, inline-level, and raw content.
Looks like it simply makes Markdown easier for both computers and humans! I love this and can’t believe I haven’t seen it before.
> Requiring quirky behavior and blank lines that hurt reading
Really? The linked spec says, referring to a blank link in indented lists:
> reStructuredText makes the same design decision.
And as a design goal:
> your document [must be] readable just as it is, without conversion to HTML and without special editor modes that soft-wrap long lines. Remember that source readability was one of the prime goals of Markdown and Commonmark…
Or this, which made me celebrate:
> anything that is indented beyond the start of the list marker belongs in the list item.
In Markdown it’s really hard (aka impossible) to get sections to respect the indentation level they belong to. What a simple rule here: inside a list, items belong to their list item. Beautiful!
Other great quotes:
> we don't need two different styles of headings or code blocks.
> avoid using doubled characters for strong emphasis. Instead… use _ for emphasis and * for strong emphasis
> code span parsing does not backtrack. So if you open a code span and don't close it, it extends to the end of the paragraph
Sanity. Sanity introduced to an ambiguous spec. It’s wonderful.
This bit made me a little unsure:
> although we want to provide the flexibility to include raw content in any output format, there is no reason to privilege HTML. For similar reasons we do not interpret HTML entities, as commonmark does
While Markdown was meant to transform to HTML, I wish it was a spec renderable without a HTML or web browser layer. So I like this. Equally though one use case I personally have is Markdown to static HTML and it’s useful having HTML tags present and handled. So my understanding of this part of the spec is confused (what does “interpret” mean?) but if it means no support for inline HTML that is indeed a pity.
> reStructuredText makes the same design decision.
"This other product that doesn't understand the appeal of Markdown and also thought this was a technical problem rather than a user barrier to entry problem made the same mistake" is not exactly a strong defense.
> Sanity. Sanity introduced to an ambiguous spec. It’s wonderful.
Users don't care how hard or easy something is to parse. You write a parser once; you write Markdown millions of times.
> Looks like it simply makes Markdown easier for both computers and humans! I love this and can’t believe I haven’t seen it before.
Unfortunately it does not. This is less readable and more annoying to write:
>Markdown:
>- Fruits
> - apple
> - orange
>
>djot:
>- Fruits
>
> - apple
> - orange
These are fundamentally different products. If you want something easy to parse and human readable, use YAML. If you want something easy to write, use Markdown.
I don’t mind pressing Enter twice instead of once.
I know that’s a glib answer. And I agree an extra line break should, to a human which reads indents, be unnecessary. But given the ambiguities of Markdown, something that is both human-readable and computer-readable is a huge advantage.
Also,
> Users don't care how hard or easy something is to parse
I don’t read it as about parsing. I read it as about writing. You can write one way and know exactly how it will be interpreted.
> So my understanding of this part of the spec is confused (what does “interpret” mean?) but if it means no support for inline HTML that is indeed a pity.
All its saying is that that djot doesn't have special rules for HTML so it spits out the same thing it receives, apparently with escaping relevant to the selected output mode. Note right above the part you quoted it shows an example of using HTML ("we simply do not allow raw HTML, except in explicitly marked contexts").
I get this, but OTOH it is IMO best to distribute digital artifacts in the format that is most useful for editing or creating derivative works. This is the free software philosophy but also a societal good. Many of us learned HTML and web technologies by reading the source code of websites, and we've closed that door behind us with all of the build steps that turn our actual code into a computer-readable-only mess which we send out for consumption by normal users' browsers. It would be nice if "view source" showed you something like what the author actually wrote in their text editor.
you can distribute websites as markdown! Return markdown with a plain text content type and it'll show as markdown, which was designed to look good as-is and not require rendering to HTML
Markdown is supposed to (be able to) look good as-is. Most people's Markdown doesn't look good as-is, though. They target the GitHub renderer and come from the GitHub-listing-as-a-product-landing-page school of thought, so even project READMEs are generally a mess.
Presumably if you want to "distribute digital artifacts in the format that is most useful for editing or creating derivative works", like parent said, you would make it look good.
This isn't an unknowable hypothetical. No need to presume anything. Markdown found in the wild is a mess. The GitHub Flavored Markdown renderer even encourages it.
Exactly this. I was paraphrasing the definition of source code from the GPL: "The source code for a work means the preferred form of the work for making modifications to it."
This is actually horrible for society as it implies that the Web Browser will have to implement a billion different parsers for all of the separate file formats it supports, which not only causes it to have a ridiculously large attack surface but pretty much implies there will only be a couple serious separate implementations (if even that soon...) as it is just too difficult for even a large company now to build a browser.
Meanwhile, it doesn't even ensure the property of being able to view source, as people can and do obfuscate things they don't want you to see, and if people want you to see the source code there is nothing preventing them from making that entirely pipeline visible, including, but certainly not limited to, shipping a trivial markdown parser to the browser instead of doing the conversion on a server.
In a perfect world, the browser should have simply provided something like canvas hooked up to something like WebAssembly, and we should have provided for everyone a trivial markup file format rendered that people could include by default and a handful of graphic file format implementations that could be easily mix-and-matched to pull just the ones people wanted into their site.
This fails to differentiate a "standard" from simply a "specification" (of a format, protocol, language...). I.e. we don't say "PostScript standard", but rather a "PostScript specification".
All of the claims they make apply to any specification, and yes, divergence is necessary to make progress.
A standard is a commonly agreed to specification, frequently ratified in one or another international organization (ISO, IETF, ECMA, W3C...). The main value of a standard is in ensuring interoperability where that matters more than all the other concerns raised.
Eg. we'd never have much of the internet if people didn't simply settle on the IP (v4) protocol.
Gemini it's the needed standard between Gopher, tied to small devices with a 80 column display, and the Web with enforced encyption for security but without requiring lots of resources.
This xkcd is always posted when anything related to a standard is mentioned, but almost never in response to a standard that was actually created to unify all standards in its space.
That's a pretty narrow reading of that XKCD: even the examples it gives are not the result of attempting to unify a set of standards.
Eg. AC chargers had a bunch of different, diverged "standards" for pretty much restricted use-cases (those 1.5mm x 4mm connectors and then micro- and mini-USB). Text encodings had multiple standards for encoding the same text (eg IBM, Windows code pages and ISO encodings) without unification attempts.
In both of these examples, there is one unifying standard added (USB-C and UTF-8 + Unicode) that did stop the proliferation of new standards.
But majority of things never result in one unifying standard that can do everything win: even SGML brough up in this discussion is an example. CORBA also springs to mind.
>There are many flavors of markdown. We'd need a standards body, compatibility suites, etc., and for all the browser vendors to adopt it.
Well, if it were to be adopted by vendors, the many flavors would be a non-problem. They can just agree on a flavor and be down with it. There's CommonMark anyway, they can just use that.
I didn't say there wasn't a standard. Just because there is a standard doesn't mean it works well. Hence the whole "more than one standard" situation...
They render as loose lists (note the ugly spacing that appears) regardless of the number of new lines between them:
https://imgur.com/VEiAZKV
The workaround is adding a tab (or other character, like a braille space) between the lists, which really makes them one list:
https://imgur.com/Z5WLy6w
I came to write something similar to this, basically.
If anything we should push for websites to divide content from presentation: if html tags were used properly there would be no need for markdown.
And on that matter, pushing for proper use of html tags in documents is a more achievable goal than asking everybody to just drop html and write markdown.
The difference is 30 years of websites and tools being built on HTML. There's an opportunity cost to consider: is formatting simple websites in Markdown and rendering them natively that much more valuable than simply writing them in HTML or using a Markdown-to-HTML tool that it's worth the cost of creating standards, implementing them in browsers, etc. as opposed to putting those efforts elsewhere?
If you were starting from scratch, maybe. But it seems like we've already reached a point where existing solutions for Markdown-to-HTML get you almost all of the value and none of the cost.
It's the extra complexity to move markdown rendering from the control/responsibility of the server side, where it fits naturally, to the user-agent side, where it doesn't -- and for something that site publisher can already do (and evidently, rarely want to do).
RFC 7763 does not define Markdown in any way. It acknowledges both the popularity and messiness of the Markdown family of syntaxes, registers a so-broad-as-to-be-nearly-useless media type for the family, and establishes a registry of variants (https://www.iana.org/assignments/markdown-variants/markdown-...).
Critically here, it does not recognise Markdown as a usable markup format in its own right. Only as a family of often ill-defined syntaxes that may be tolerably readable in raw form, and with the correct, unspecified tools may be converted to a formal markup language like HTML.
“Markdown” is utterly unsuitable as a publishing format. It’s designed as a writing format.
>Markdown is a text-to-HTML conversion tool for web writers. Markdown allows you to write using an easy-to-read, easy-to-write plain text format, then convert it to structurally valid XHTML (or HTML).
> Thus, “Markdown” is two things: (1) a plain text formatting syntax; and (2) a software tool, written in Perl, that converts the plain text formatting to HTML.
I believe nowadays most people refer to (1) instead of Perl tool, when talking about Markdown.
Personally I use Markdown *a lot* for Flutter apps, where text is rendered natively. Also use it for legal documents, which are converted to PDF via pandoc. Another project I have is a console app that also shows formatted help text written in Markdown. In all these cases there is no HTML whatsoever and no 'text-to-HTML conversion tool'. Yet it's all Markdown, so no need to reduce its applications to HTML, let alone claiming that it's designed "to transform to HTML".
There are many flavors of markdown. We'd need a standards body, compatibility suites, etc., and for all the browser vendors to adopt it.
Meanwhile, markdown is designed to transform to HTML, which browsers already render. Adding a markdown-to-html plugin/step to your web server or publishing process is not exactly the most burdensome thing, relative to everything else it takes to develop, publish, and maintain a site. And it resolves the markdown flavors issue.
The thing is, people could choose to publish, simple uncomplicated sites now -- it would be cheap and easy, too. The HTML is barely more complicated than the equivalent markdown, and it would take a few lines of CSS to apply a basic style.
The many sites that choose to be complicated, cluttered, and expensive will continue to be so, for the same reasons they are now. Markdown would just be another way to build simple sites, which they don't want.