Hacker News Reader

Comment by falcolas | Hacker News Reader

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

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

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.

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.

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.

I would be on-board with this as long as we compile everything into WebAssembly with Emscripten first

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.

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?

CommonMark seems like the obvious choice: 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.

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.

Forget math, CommonMark doesn't even handle tables.

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.

> CommonMark is a decent solution to "I want to use Markdown", if you're willing to take the simplification.

It would be very hard to make a case for CommonMark over something like Pandoc markdown, given that it does so much more than CommonMark.

Note that the discussion here is markdown inside a browser. That's not a good place to go with a dramatic simplification.

I feel like you read the quoted sentence and stopped. I talk about both the browser and simplification further on, literally the next sentence.

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.

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…

In fact, github itself can already render it out. Markdown based websites hosted for free on github: https://www.markdownguide.org/tools/github-pages/

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

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.

Asciidoc.

> 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?

It's basically a dsl to generate markdown.

People who propose replacing markdown with AsciiDoc completely miss the point of Markdown in my opinion.

Asciidoc is not in any way a dsl to generate markdown. Being far more expressive than markdown would obviously prevent that.

HTML

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

  ---
  Dialect: GFM
  ---

That's what I do at taoofmac.com internally. The whole thing is a mix of Textile, Markdown and HTML

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.

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

myst

Reply on news.ycombinator.com