5 ms·

OK. Which flavor of markdown should we get every browser manufacturer to use?

by falcolas 4y ago

djbusby 4y ago
Asciidoc.
- GartzenDeHaes 4y ago
  > AsciiDoc is a plain text markup language for writing technical content. It’s packed with semantic elements and equipped with features to modularize and reuse content. Isn't that the opposite of Markdown?
  - maximus-decimus 4y ago
    It's basically a dsl to generate markdown. People who propose replacing markdown with AsciiDoc completely miss the point of Markdown in my opinion.
    - pessimizer 4y ago
      Asciidoc is not in any way a dsl to generate markdown. Being far more expressive than markdown would obviously prevent that.
BeefWellington 4y ago
I made a comment about how to do this as my very first HN post on this account[1] in a code-golf-y sort of thread: Here's the example: # Markdown header ## Subheader ### Section header 1. Numbered 1. List - Unordered - List [//]: # (<html><body></body><script src="https://cdn.jsdelivr.net/npm/marked/marked.min.js"></script><script>var doc = document.children[0].textContent.split('\n'); md = doc.slice(0, doc.length - 1).join("\n"); document.body.innerHTML = marked(md);</script></html><!--) Now, whether this is wise to encourage or not I can't speak to. It would be great if browsers parsed markdown as text-only [1]: https://news.ycombinator.com/item?id=25352385#25355751 https://news.ycombinator.com/item?id=25352385#25355751
- piskerpan 4y ago
  Nice! You don't need the HTML and BODY tags though. I think however this defeats the purpose: yes you're delivering the content as Markdown, but you have to deliver it as `text/html` for it to be rendered, so anyone fetching it can't tell it's Markdown content. Also every document has to have (invisible-ish) HTML junk appended A "better" solution would be a browser that sends the `Accept: text/markdown, text/html` header and a server that serves Markdown only when requested.
lake_vincent 4y ago
Let's just embrace the chaos and develop a new flavor for every browser until there are precisely 31 different flavors of Markdown. We cap it there, Baskin Robbins style, and then watch the world burn.
- deleted 4y ago
  [deleted]
- thih9 4y ago
  We could have a higher level language and tooling that transpiles everything to all known markdown flavors and bundles them all. But I guess one of these 31 flavors already does that.
  - ihatepython 4y ago
    I would be on-board with this as long as we compile everything into WebAssembly with Emscripten first
    - deleted 4y ago
      [deleted]
BiteCode_dev 4y ago
myst
reichardt 4y ago
HTML
Ideabile 4y ago
This is the reason why Markdown isn't a good specification for this. But I do agree with the sentiment.
ohgodplsno 4y ago
Make a World Wide Markdown Consortium, release v1 of Markdown based on a randomly picked flavor, let it stagnate for decades, then let Google implement shadowMarkdown in Google Chrome, which renders at 300FPS for them, and unluckily falls back to a JS polyfill that ends up solving a rubik's cube before every character it renders. Once that has gone for long enough, let Google form their own MHATWG and pretend it's open while they keep a majority of the seats, to steer the evolution of WebMarkdown. Also Safari still doesn't support headings for some reason.
falcolas 4y ago
My personal preference would be GitHub flavored markdown, since as a coder it includes a lot of very useful non-standard markups. The compromises it makes on the non-deterministic markup elements are acceptable as well.
- acomjean 4y ago
  I think this makes sense. Many of the GitHub readmes are in markdown already, so people are quite familiar with it and there might already be an open source package that renders it out…
  - bonestamp2 4y ago
    In fact, github itself can already render it out. Markdown based websites hosted for free on github: https://www.markdownguide.org/tools/github-pages/ https://www.markdownguide.org/tools/github-pages/
    - acomjean 4y ago
      I guess it wasn't clear, but I meant those markdowns are rendered on everyones github page.. But the whole github pages thing is new to me. Very cool and seems like what the blog post was asking for. Its using "Jekyll" to render those "github-pages" sites https://github.com/jekyll/jekyll https://github.com/jekyll/jekyll
- toastal 4y ago
  Like how they're introducing admonitions syntax by overloading the blockquote sigil that makes it difficult or impossible to nest, has a heavy English bias, and doesn't even transform the underlying element making the use of blockquote unsemantic. They also just skipped the CommonMark RFC and other implementations throwing their weight into the ring with no regard for prior art. I also don't think a corporation, Microsoft, needs to be in charge of the spec either. No thank you.
jerf 4y ago
CommonMark seems like the obvious choice: https://commonmark.org/ https://commonmark.org/ It isn't as supported as I'd like, but it does exist and I've encountered it "in the wild" a few times, so it's not just some guy typing away on a website either.
- bachmeier 4y ago
  After all these years, I still haven't found an important argument in favor of CommonMark. As I point out every time someone presents it as the answer, it doesn't handle things like math, so you still need to use unstandardized extensions, making the whole thing pointless.
  - The_Colonel 4y ago
    Forget math, CommonMark doesn't even handle tables.
  - jerf 4y ago
    The argument is that if you disqualify everything for not having $FEATURE, where $FEATURE varies from person to person, you have also essentially disqualified markdown entirely. As the saying goes, everyone uses only 10% of Microsoft Word, but everyone uses a different 10% of Microsoft Word. Much the same thing applies to this case for much the same reasons. If your standard is going to be "I want everything in any variant of Markdown ever and also any plugin ever", you will end up with something that is just as complicated as HTML, only different this time. (Possibly even more complicated than HTML.) CommonMark is a decent solution to "I want to use Markdown", if you're willing to take the simplification. Note in this case I don't think there's anything wrong with refusing the simplification. It's just that if that is your set of your requirements, you've disqualified Markdown entirely. Personally, I think that is the state of the situation; Markdown can't do this. Markdown and all of its family members and close friends intrinsically work by reducing the problem. If you refuse to reduce the problem, you've refused to use Markdown. That is not a moral judgment; that's an engineering judgment. From the position the major browsers operate in, they will never attain anywhere near enough agreement on this to ever implement it without it simply becoming another monster of its own as everybody piles in with all their favorite extensions. I have some websites that run with Hugo, which is in principle based on Markdown, but if necessary you can have raw HTML pages or other things too. This is actually the ideal; use Markdown when it makes sense, use other things when it doesn't, and thus, neither of those two things has to carry the burdens of the other side. This is the real and best solution, honestly, and it also has the advantage that it's here now. Use whatever flavor you want, where ever you want, whenever you want, today. I'm doing this and I don't see any advantage to trying to convince the browser to do this. I have a deploy step regardless of what I do, so it's no skin off my nose whether that step deploys my pages raw or there's a render step in addition to the deploy.
miroljub 4y ago
Why not use org-mode format, which is a much saner markup language? Being there, why not just implement full org-mode in browsers natively, and use it instead of html?
euroderf 4y ago
Many Markdown dialects are adopting YAML metadata, so why not start a file with (for example) --- Dialect: GFM ---
- rcarmo 4y ago
  That's what I do at taoofmac.com internally. The whole thing is a mix of Textile, Markdown and HTML
- toastal 4y ago
  All dialects of Org Mode, AsciiDoc, reStructuredText, HTML files, ODF files, EXIF data on images support metadata in file--it's the norm. The fact that Markdown's spec doesn't support metadata by default and most "dialects" don't this ad hoc syntax (YAML of all broken things) shows that Markdown not suitable for most kinds of documents.

OK. Which flavor of markdown should we get every browser manufacturer to use?

djbusby 4y ago

Asciidoc.

GartzenDeHaes 4y ago
> AsciiDoc is a plain text markup language for writing technical content. It’s packed with semantic elements and equipped with features to modularize and reuse content. Isn't that the opposite of Markdown?
- maximus-decimus 4y ago
  It's basically a dsl to generate markdown. People who propose replacing markdown with AsciiDoc completely miss the point of Markdown in my opinion.
  - pessimizer 4y ago
    Asciidoc is not in any way a dsl to generate markdown. Being far more expressive than markdown would obviously prevent that.

BeefWellington 4y ago

I made a comment about how to do this as my very first HN post on this account[1] in a code-golf-y sort of thread: Here's the example: # Markdown header ## Subheader ### Section header 1. Numbered 1. List - Unordered - List [//]: # (<html><body></body><script src="https://cdn.jsdelivr.net/npm/marked/marked.min.js"></script><script>var doc = document.children[0].textContent.split('\n'); md = doc.slice(0, doc.length - 1).join("\n"); document.body.innerHTML = marked(md);</script></html><!--) Now, whether this is wise to encourage or not I can't speak to. It would be great if browsers parsed markdown as text-only [1]: https://news.ycombinator.com/item?id=25352385#25355751 https://news.ycombinator.com/item?id=25352385#25355751

piskerpan 4y ago
Nice! You don't need the HTML and BODY tags though. I think however this defeats the purpose: yes you're delivering the content as Markdown, but you have to deliver it as `text/html` for it to be rendered, so anyone fetching it can't tell it's Markdown content. Also every document has to have (invisible-ish) HTML junk appended A "better" solution would be a browser that sends the `Accept: text/markdown, text/html` header and a server that serves Markdown only when requested.

lake_vincent 4y ago

Let's just embrace the chaos and develop a new flavor for every browser until there are precisely 31 different flavors of Markdown. We cap it there, Baskin Robbins style, and then watch the world burn.

deleted 4y ago
[deleted]
thih9 4y ago
We could have a higher level language and tooling that transpiles everything to all known markdown flavors and bundles them all. But I guess one of these 31 flavors already does that.
- ihatepython 4y ago
  I would be on-board with this as long as we compile everything into WebAssembly with Emscripten first
  - deleted 4y ago
    [deleted]

BiteCode_dev 4y ago

myst

reichardt 4y ago

HTML

Ideabile 4y ago

This is the reason why Markdown isn't a good specification for this. But I do agree with the sentiment.

ohgodplsno 4y ago

Make a World Wide Markdown Consortium, release v1 of Markdown based on a randomly picked flavor, let it stagnate for decades, then let Google implement shadowMarkdown in Google Chrome, which renders at 300FPS for them, and unluckily falls back to a JS polyfill that ends up solving a rubik's cube before every character it renders. Once that has gone for long enough, let Google form their own MHATWG and pretend it's open while they keep a majority of the seats, to steer the evolution of WebMarkdown. Also Safari still doesn't support headings for some reason.

falcolas 4y ago

My personal preference would be GitHub flavored markdown, since as a coder it includes a lot of very useful non-standard markups. The compromises it makes on the non-deterministic markup elements are acceptable as well.

acomjean 4y ago
I think this makes sense. Many of the GitHub readmes are in markdown already, so people are quite familiar with it and there might already be an open source package that renders it out…
- bonestamp2 4y ago
  In fact, github itself can already render it out. Markdown based websites hosted for free on github: https://www.markdownguide.org/tools/github-pages/ https://www.markdownguide.org/tools/github-pages/
  - acomjean 4y ago
    I guess it wasn't clear, but I meant those markdowns are rendered on everyones github page.. But the whole github pages thing is new to me. Very cool and seems like what the blog post was asking for. Its using "Jekyll" to render those "github-pages" sites https://github.com/jekyll/jekyll https://github.com/jekyll/jekyll
toastal 4y ago
Like how they're introducing admonitions syntax by overloading the blockquote sigil that makes it difficult or impossible to nest, has a heavy English bias, and doesn't even transform the underlying element making the use of blockquote unsemantic. They also just skipped the CommonMark RFC and other implementations throwing their weight into the ring with no regard for prior art. I also don't think a corporation, Microsoft, needs to be in charge of the spec either. No thank you.

jerf 4y ago

CommonMark seems like the obvious choice: https://commonmark.org/ https://commonmark.org/ It isn't as supported as I'd like, but it does exist and I've encountered it "in the wild" a few times, so it's not just some guy typing away on a website either.

bachmeier 4y ago
After all these years, I still haven't found an important argument in favor of CommonMark. As I point out every time someone presents it as the answer, it doesn't handle things like math, so you still need to use unstandardized extensions, making the whole thing pointless.
- The_Colonel 4y ago
  Forget math, CommonMark doesn't even handle tables.
- jerf 4y ago
  The argument is that if you disqualify everything for not having $FEATURE, where $FEATURE varies from person to person, you have also essentially disqualified markdown entirely. As the saying goes, everyone uses only 10% of Microsoft Word, but everyone uses a different 10% of Microsoft Word. Much the same thing applies to this case for much the same reasons. If your standard is going to be "I want everything in any variant of Markdown ever and also any plugin ever", you will end up with something that is just as complicated as HTML, only different this time. (Possibly even more complicated than HTML.) CommonMark is a decent solution to "I want to use Markdown", if you're willing to take the simplification. Note in this case I don't think there's anything wrong with refusing the simplification. It's just that if that is your set of your requirements, you've disqualified Markdown entirely. Personally, I think that is the state of the situation; Markdown can't do this. Markdown and all of its family members and close friends intrinsically work by reducing the problem. If you refuse to reduce the problem, you've refused to use Markdown. That is not a moral judgment; that's an engineering judgment. From the position the major browsers operate in, they will never attain anywhere near enough agreement on this to ever implement it without it simply becoming another monster of its own as everybody piles in with all their favorite extensions. I have some websites that run with Hugo, which is in principle based on Markdown, but if necessary you can have raw HTML pages or other things too. This is actually the ideal; use Markdown when it makes sense, use other things when it doesn't, and thus, neither of those two things has to carry the burdens of the other side. This is the real and best solution, honestly, and it also has the advantage that it's here now. Use whatever flavor you want, where ever you want, whenever you want, today. I'm doing this and I don't see any advantage to trying to convince the browser to do this. I have a deploy step regardless of what I do, so it's no skin off my nose whether that step deploys my pages raw or there's a render step in addition to the deploy.

miroljub 4y ago

Why not use org-mode format, which is a much saner markup language? Being there, why not just implement full org-mode in browsers natively, and use it instead of html?

euroderf 4y ago

Many Markdown dialects are adopting YAML metadata, so why not start a file with (for example) --- Dialect: GFM ---

rcarmo 4y ago
That's what I do at taoofmac.com internally. The whole thing is a mix of Textile, Markdown and HTML
toastal 4y ago
All dialects of Org Mode, AsciiDoc, reStructuredText, HTML files, ODF files, EXIF data on images support metadata in file--it's the norm. The fact that Markdown's spec doesn't support metadata by default and most "dialects" don't this ad hoc syntax (YAML of all broken things) shows that Markdown not suitable for most kinds of documents.