[kccqzy]

Markdown has always supported direct raw HTML in it. I don't see any gulf or sudden jump in cost. Don't be a Markdown purist. Even John Gruber, the creator of Markdown, is not a Markdown purist. Go look at the Markdown source of his blog and you will see that he frequently just uses raw HTML. He doesn't even do multi-paragraph ordered lists in Markdown, and chooses to write <ol><li><p> instead. And he also uses <a><img> for clickable images. You can append ".text" to any of his blog article to get the Markdown source; example https://daringfireball.net/2020/10/the_iphone_12_and_iphone_...

[aylmao]

On the note of embedding HTML in Markdown, I think it'd be cool if it were just as easy to embed Markdown in HTML. Something akin to a <markdown> tag.

Markdown makes it easy to write formatted content at the cost of initial compiler setup, HTML is 0-cost setup but takes some effort to write formatted content. With a <markdown> tag one could start with vanilla HTML at zero cost, use all its features straight away, but not have to type HTML for the simple, "content" parts of a site.

EDIT: there seem to be web components for this already:

- https://github.com/xan105/web-component-markdown

- https://www.webcomponents.org/element/zero-md

- https://www.webcomponents.org/element/@vanillawc/wc-markdown

[tducret]

Take a look at https://www.tducret.com/pure-markdown It's just a single JS script import, and then plain Markdown. You can host it as-is, no build required (à la Jekyll, Hugo...).

You can verify the content with : curl https://www.tducret.com/pure-markdown/

[TheRealPomax]

That sounds like a good idea, until you remember that there is no officially agreed upon markdown spec. For content authors it'd be both fantastic if browsers could just go "you guys go fight it out, we're just gonna go with GitHub flavored markdown" but at the same time for browser makers that's taking a position on something that they have no stake in.

So writing or using someone else's custom element is pretty much your only option here.

[bityard]

There is a Markdown spec: https://commonmark.org

Although of course in practice, commonmark renderers are not plentiful or up to date. In my experience, most library authors end up just implementing the bits of Markdown they care about and the behavior they prefer for the ambiguous parts.

[TheRealPomax]

There are multiple markdown specs. This is one of them, probably the most well-known, but certainly not the only one.

[alsetmusic]

“This is my Markdown. There are many like it but this one is mine.”

[wrboyce]

Obligatory https://xkcd.com/927/

[MrVandemar]

https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=fa...

[aylmao]

yeah, I wasn't hypothesizing this as something that should be added natively to browsers. Web is complicated enough officially supporting 3 languages (or 6, if you consider wasm, webgl and wgsl)

Though for what its worth, "no official agreed upon spec" didn't stop browsers before haha

[zelphirkalt]

It will probably never happen, because the browser would need to translate to HTML anyway, before rendering it. At that point it could simply be done beforehand on the server, not putting more tasks onto the browser and adding the complexities of HTML inside md inside HTML inside md ... and so on.

[latexr]

> Even John Gruber, the creator of Markdown, is not a Markdown purist. Go look at the Markdown source of his blog and you will see that he frequently just uses raw HTML.

John Gruber is the worst possible authority to reference here. He’s a bad steward of the standard and Markdown is popular despite him, not because of him. His own implementation has bugs that will never be fixed, doesn’t support features we all take for granted as basic Markdown, and he refused to even acknowledge when someone wanted to make a proper standard out of it. If Markdown were left to him, none of us would be using it and would have come up with something inspired by it but probably better and without a myriad of competing implementations with different levels of support.

> Go look at the Markdown source of his blog and you will see that he frequently just uses raw HTML.

In situations where, if he used any parser other than his own stagnant code, the whole post could have been written in Markdown. For crying out loud, in the page you linked he has Markdown tables (which his parser does not support) inside HTML comments followed by HTML tables. Daring Fireball is a popular site, but it’s not an example of good design or content structuring. To this day it’s still annoying to read on mobile.

[briandoll]

100% this -- we tried to work with JG to create and support a Markdown standard when we formalized "GitHub flavored Markdown" and got the exact opposite reaction many of us expected. Even using the name in any context was seen as a slight.

More context:

https://github.blog/engineering/user-experience/a-formal-spe...

https://github.github.com/gfm/

[scblock]

Dude created a simple tool based on email conventions of the time and released it to the world for free and it's still with us, used all over. And you're here crying that he didn't want to work with you? Did you think he was somehow obligated to? How incredibly entitled.

It's open source, so you do what you do. That's the good and bad of it. No one owes you a god damned thing.

[belak]

I think you're missing much of the context and are misrepresenting what happened.

As far as I'm aware, there was no crying he didn't want to work with people, but there was a frustration that he was not open to having a Markdown "standard". To the point where he actively opposed efforts to standardize it, at least under the name Markdown[1].

This is legally and technically fine, as he owns a trademark for Markdown, but when you combine the inconsistent application of that trademark (GitHub Flavored Markdown is seemingly fine, but Common Markdown was not), along with him calling it "Jeff Atwood's crusade" and mocking the effort[2], it's not a great look and resulted in quite a few frustrated people.

As an open source project, you're right that he doesn't owe anything to anyone, but that doesn't mean people have to be entirely happy about how the situation was handled either.

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

[2]: https://soundcloud.com/thetalkshow/ep-88-cat-pictures-side-1, around 1:15

[latexr]

> As an open source project

But it’s not an open-source project. It’s a download link to a Perl script which is never updated and effectively no one uses.

There’s currently zero value to the code he wrote or the reference in his page. The only thing of worth that remains of his original implementation is the concept and the most basic syntax.

[the_af]

The point is Gruber was contacted out of courtesy, his name as the initial author carrying some weight in people's minds, and he reacted in an openly hostile and mocking way.

[marxisttemp]

I listen to a few podcasts that Gruber is a friend of, but he’s always struck me as a bit vapid and haughty. He always seems to reference his own influence, which he seems to have earned by…coming up with a handful of basic text markup syntax and writing Apple hagiographies?

[the_af]

I always wondered why anybody would "support" or subscribe to the microblog of someone whose profession seems to be "write about Apple, mostly defending them". And not in any detailed long form, either.

[kccqzy]

I don't enjoy the fact that he's obviously biased and defends Apple too often, and occasionally shows his lack of technical understanding. But this man's job is writing and he writes better than 90% of blog posts posted on HN. And he has plenty of long form posts. His iPhone reviews are often longer than most tech journalists' reviews. I often disagree with the contents of his writing, but I do have a soft spot for people who wield language well.

[the_af]

Gruber also had a famously snotty reaction to Jeff Atwood (of coding horror, stackoverflow, Discourse and others) contacting him about standardizing markdown.

I won't rehash it here, it's been mentioned before both here and in Coding Horror (Atwood's blog)

[cdchn]

At that point, why aren't you just writing HTML?

[dannyobrien]

Markdown is really just a way of making the average, text, bit of HTML a little bit easier to read and write. Even when you're including some HTML in it, it still has that advantage over raw HTML.

[fragmede]

<p>because, it is <i>really</i> awkward</p>

[cdchn]

All the hoops you have to jump through with Markdown seem more awkward to me than a few extra characters.

[fragmede]

but you jump through those hoops during setup, vs seven extra characters every paragraph

[cdchn]

But then you just end up writing HTML anyways.

[fragmede]

the output is html, but when you're writing markdown thought flows to output more seamlessly, with fewer characters vs with having to close italics with the more awkward </i>. yeah in the end that goes through a tool and it outputs html, but it's about when I'm trying to get the ideas out of my head and onto the page.

[AceJohnny2]

> I don't see any gulf or sudden jump in cost.

Then you missed the core point of the article, so I'll try and rephrase it:

While you're staying in Markdown-only land (the left part of the article's graph halfway down the article: low-medium richness (horizontal), very low complexity (vertical)), you are not learning HTML.

You miss the "onboarding" process to the richness of HTML, so when you reach the limits of what Markdown can do, and suddenly you need something medium-rich... you have to play catch-up to learn all the HTML that you avoided by sticking to Markdown. That's the gap.

The fact that Markdown supports in-line HTML allows you to bridge the gap, but is irrelevant to the point.

[tacticus]

You're not learning html when you write react horror shows either.

it's a space that broke <A /> because they're too useful and needed a broken react special version.

[gwern]

Yeah, I don't buy the theory either. Markdown has always made it easy to just drop in a bit of HTML wherever you need it, and major dialects like Pandoc Markdown support even more. You can set class, ID, and data-attributes on most elements, such as links, or write any div/span placeholder you need natively. (I don't even bother to use the native syntax because writing a '<div class="foo">bar</div>' is so easy.) What 'rich' features is that impeding?

I can say that on my website, which is certainly 'richer' than most Markdown-oriented websites, we scarcely ever think about Markdown as a limitation to implementing a feature. Nor was it a serious hindrance at any point. There have been issues, sure, but pretty much never do we tear our hair out going, 'how can we possibly implement transclusion properly, when the source is written in Markdown rather than Asciidoc??? Woe is us!' That's just not a thing.

When we have issues, it's almost always related to something about the Pandoc internal API design choices (essentially unrelated to any syntactic sugar and would be equally true if we were starting from a different input type) or the sheer difficulty of implementing anything well & reliably cross-platform/device/mode. The Markdown part of our discussions usually boils down to a debate over the naming of a class. Because setting the class on whatever element is a non-problem, already solved, and we move on to the real challenges to adding a rich feature.

To whatever extent his imaginary gap exists in reality, I would bet it has far more to do with dynamics around websites which happen to use Markdown, like trying to cater to the lowest-common denominator and banning HTML fragments, and stuff like that.

[josephg]

So? I could write my blog post in raw HTML without using any markdown at all. But we don't, because raw HTML is a bad tool for composing rich content.

The kind of things I want to be able to do (that markdown makes hard):

- Make a standard component for embedded images, which supports clicking the image to see it full-screen.

- Make "boxes", showing certain kinds of content. This is useful for diagrams, commentary, code, formulas, and more depending on what you're doing.

- Run code when building the page which can load external data and display it however I want. For example, I wrote a paper using typst recently. I have some data in a JSON file. My typst paper contains code to read in the JSON file and embed some of the values into a table in the output.

- Embed raw SVGs into the output, in an svg tag.

- Have programmatic content - eg, onclick handlers, hover states, etc.

- Make a table of contents (I think GFM supports this, but I don't think its a standard markdown feature)

- Have generated section titles (Eg "3.a Benchmark results")

- Make a webpage which contains content from a lot of markdown files in a folder. Each of those files may need custom ... well, everything.

- Use custom CSS styles. Styles might be local (just this element) or global across the page.

- Use extensions / plugins for things like programmatic diagrams

Raw HTML is a complete non-answer to this stuff. Its the sort of answer that makes me question if you've done any serious writing at all. Like, your comment reads to me as the writing equivalent of arguing that C is the best programming language because - if you need anything thats not in C, you can write it in assembly.

What I really want is some combination of markdown + react. Typst is close - or, it will be close once it supports HTML output. But markdown simply isn't powerful enough for serious writing.

[apitman]

I wish more sites offered plain text versions. You can read mine with netcat:

nc apitman.com 2052 <<< /txt/feed

[djbusby]

On HTTP one can use the Accept header to indicate desired response type.

[apitman]

Sadly, content negotiation has fallen out of favor