4 ms·

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 M

• aylmao 2y ago
  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://github.com/xan105/web-component-markdown - https://www.webcomponents.org/element/zero-md https://www.webcomponents.org/element/zero-md - https://www.webcomponents.org/element/@vanillawc/wc-markdown https://www.webcomponents.org/element/@vanillawc/wc-markdown
  • TheRealPomax 2y ago
    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.
    • aylmao 2y ago
      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
    • bityard 2y ago
      There is a Markdown spec: https://commonmark.org 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 2y ago
        There are multiple markdown specs. This is one of them, probably the most well-known, but certainly not the only one.
        • alsetmusic 2y ago
          “This is my Markdown. There are many like it but this one is mine.”
        • wrboyce 2y ago
          Obligatory https://xkcd.com/927/ https://xkcd.com/927/
          • MrVandemar 2y ago
            https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=false&query=xkcd.com%2F927%2F&sort=byDate&type=comment https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=fa...
  • tducret 2y ago
    Take a look at https://www.tducret.com/pure-markdown 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/ https://www.tducret.com/pure-markdown/
  • zelphirkalt 2y ago
    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.
• cdchn 2y ago
  At that point, why aren't you just writing HTML?
  • dannyobrien 2y ago
    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 2y ago
    <p>because, it is <i>really</i> awkward</p>
    • cdchn 2y ago
      All the hoops you have to jump through with Markdown seem more awkward to me than a few extra characters.
      • fragmede 2y ago
        but you jump through those hoops during setup, vs seven extra characters every paragraph
        • cdchn 2y ago
          But then you just end up writing HTML anyways.
          • fragmede 2y ago
            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.
• latexr 2y ago
  > 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 2y ago
    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-spec-for-github-markdown/ https://github.blog/engineering/user-experience/a-formal-spe... https://github.github.com/gfm/ https://github.github.com/gfm/
    • scblock 2y ago
      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.
• apitman 2y ago
  I wish more sites offered plain text versions. You can read mine with netcat: nc apitman.com 2052 <<< /txt/feed
  • djbusby 2y ago
    On HTTP one can use the Accept header to indicate desired response type.
    • apitman 2y ago
      Sadly, content negotiation has fallen out of favor
• gwern 2y ago
  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 2y ago
  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.
• AceJohnny2 2y ago
  > 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 2y ago
    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.