We should have Markdown-rendered websites

Markdown is a convenient but deeply limited markup language with only a small subset of html&#x27;s features. And yes, limitations are good because we want documents not web apps, etc, etc, but I mean &quot;images can&#x27;t have captions&quot; limited, &quot;navigation bars don&#x27;t exist&quot; limited. Actual important features of html don&#x27;t exist in markdown, which is why almost every markdown platform ends up adding extensions and shortcodes. Why use markdown at all? Just use html.<p>&quot;But html isn&#x27;t style-agnostic&quot; yes it is. <i>CSS</i> isn&#x27;t style-agnostic. Instead of a markdown browser, how about a browser with a fixed stylesheet and no js? You don&#x27;t even need a browser for that, that could just be a userscript that gets plugged into an existing browser. It&#x27;d break non-compliant websites that require javascript or custom css, but so would a markdown browser. Most people wouldn&#x27;t write content for it, but most people wouldn&#x27;t write content for a markdown browser either.<p>&quot;But html is cluttered&quot; it doesn&#x27;t have to be. This is a valid webpage:<p><pre><code> &lt;!doctype html&gt; &lt;title&gt;Page Title&lt;&#x2F;title&gt; &lt;h1&gt;Page Title&lt;&#x2F;h1&gt; &lt;p&gt;Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut ac lorem ut massa euismod vestibulum. &lt;p&gt;Nullam rutrum blandit eleifend. Aenean a varius diam. Morbi sodales velit nunc, vel vestibulum lorem tempus sodales. </code></pre> Personally, I prefer writing in markdown, but that&#x27;s no reason to insert a markdown renderer into browsers. HTML can already be as sleek and readable as you want. If we added a new type of markup for anybody with a personal preference, we&#x27;d never stop.

This doesn&#x27;t really make sense, for a couple reasons...<p>There are many flavors of markdown. We&#x27;d need a standards body, compatibility suites, etc., and for all the browser vendors to adopt it.<p>Meanwhile, markdown is designed to transform to HTML, which browsers already render. Adding a markdown-to-html plugin&#x2F;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.<p>The thing is, people could <i>choose</i> 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.<p>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&#x27;t want.

HTML is already a markup language. You could just as easily make basic websites using HTML and some basic inline CSS.<p>(They’d even have some extra features missing from Markdown that I’d consider still part of a basic content formatting suite like floating or multi-column layouts. They’d even have a defined standard for machine readable metadata!)<p>The problem is that people don’t make websites like that very often, even though they can. This is trying to solve a problem that doesn’t currently exist.

This misses the real point of Markdown, which isn&#x27;t to be simple or opinionated but to be <i>readable</i> by the end user in both forms (raw or rendered).<p>In case of a web site there is never the expectation of the source being easy to read for the end user. If you want to create a simple page – great, go for it. The only minor change will be replacing markdown tags with HTML ones. And there&#x27;s plenty of tooling which does that trivially.

Deliver as markdown, but with a single line header:<p><pre><code> &lt;!DOCTYPE html&gt;&lt;title&gt;Foo&lt;&#x2F;title&gt;&lt;script src=mydelayedmarkdownparser.js&gt;&lt;&#x2F;script&gt;&lt;PLAINTEXT&gt; [[insert your markdown here]] </code></pre> A document delivered as pure markdown, that will get spidered by any search engine that renders JavaScript (or that reads the document as text), and you don’t need to ask anyone to change anything. HTML has no closing &lt;&#x2F;plaintext&gt; end tag, so markdown can be free-form and securely include any unescaped <i>&lt;&gt;”’</i> characters (raw HTML code) you need into your markdown and the browser will treat it as pure text (unlike the &lt;XMP&gt; tag which can be ended with &lt;&#x2F;XMP&gt; - even weirder lexing).<p>The key is that although the &lt;plaintext&gt; tag is deprecated, every browser has to support it (partially because removing support for &lt;plaintext&gt; would cause security issues for existing pages!) The &lt;plaintext&gt; tag is really very special, quite different from any other tag, and it radically interrupts HTML document lexing&#x2F;parsing.<p>Use something like <a href="https:&#x2F;&#x2F;whatismarkdown.com&#x2F;how-to-have-markdown-in-realtime-javascript&#x2F;" rel="nofollow">https:&#x2F;&#x2F;whatismarkdown.com&#x2F;how-to-have-markdown-in-realtime-...</a> to read the content of the &lt;plaintext&gt; and dynamically render your markdown into HTML.<p><a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;HTML&#x2F;Element&#x2F;plaintext" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;HTML&#x2F;Element&#x2F;pl...</a><p>Edit: and of course there is the HTTP header <i>Content-Type: text&#x2F;markdown</i> which could be used by browsers to render a markdown document - see “The text&#x2F;markdown Media Type” RFC <a href="https:&#x2F;&#x2F;www.rfc-editor.org&#x2F;rfc&#x2F;rfc7763.html" rel="nofollow">https:&#x2F;&#x2F;www.rfc-editor.org&#x2F;rfc&#x2F;rfc7763.html</a> and <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;HTTP&#x2F;Headers&#x2F;Content-Type" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;HTTP&#x2F;Headers&#x2F;Co...</a>

I mean it _sounds_ good, but how will we cram a million ads down user&#x27;s throats and measure every twitch of their input devices? It&#x27;s almost as though the author is suggesting that web site proprietors might be more interested in &quot;serving content&quot; than &quot;driving engagement&quot; which I find disturbing and upsetting.<p>&#x2F;s

People are &quot;big-picture&quot; missing why this is an important idea. I had a prof put it like this once: The great tragedy of the web is the following:<p>HTML made the web easy to read.<p>But you know what made the web easy to write? Facebook. Facebook was undeniably the technology that made it so that roughly <i>everybody</i> could write things on the web to be read by everyone.<p>I really like the direction of this, because it points toward the possibility of a &quot;web that is easy to write.&quot;

You already can render markdown. It shows as what it is: text.<p>If you want to render markdown as something else, you need to define what that other thing is. If you&#x27;re suggesting we render it as a webpage, well webpages are made of HTML and CSS--so you&#x27;re saying you want to render markdown as HTML&#x2F;CSS.<p>We can already do that. There are a plethora of tools available to do that.

Gemini. You&#x27;re describing Gemini.<p><a href="https:&#x2F;&#x2F;gemini.circumlunar.space&#x2F;" rel="nofollow">https:&#x2F;&#x2F;gemini.circumlunar.space&#x2F;</a>

FWIW, just a couple of weeks ago we started doing that for a new sqlite subproject: <a href="https:&#x2F;&#x2F;sqlite.org&#x2F;wasm" rel="nofollow">https:&#x2F;&#x2F;sqlite.org&#x2F;wasm</a><p>With the exception of one page, all of them are markdown, rendered on demand by the Fossil SCM. The one exception is an HTML file, which we need in order to host a small JS application.

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

isn&#x27;t this why HTML was invented?<p>agree that it&#x27;d be nice to have a markdown file be rendered inherently within the browser so i don&#x27;t have to use haroopad on my windows machine, but it feels like we&#x27;re just going to reinvent HTML

If Google upranked “documents” (simple HTML content without JavaScript), then there would be an incentive to publish simple content.<p>Instead Google goes to insane lengths to parse JavaScript generated abominations, and otherwise allow&#x2F;encourage shitty content.

Part of the benefit of Markdown is that you can view the raw source and still get useful info out of it. But this site prerendered the Markdown and served HTML which defeats part of the purpose.<p>A better option would be to use something like <a href="https:&#x2F;&#x2F;casual-effects.com&#x2F;markdeep&#x2F;" rel="nofollow">https:&#x2F;&#x2F;casual-effects.com&#x2F;markdeep&#x2F;</a> and serve the MD&#x2F;HTML file. Then you can get a client-rendered HTML (<a href="https:&#x2F;&#x2F;casual-effects.com&#x2F;markdeep&#x2F;features.md.html" rel="nofollow">https:&#x2F;&#x2F;casual-effects.com&#x2F;markdeep&#x2F;features.md.html</a>) or view the raw MD (<a href="https:&#x2F;&#x2F;casual-effects.com&#x2F;markdeep&#x2F;features.md.html?noformat" rel="nofollow">https:&#x2F;&#x2F;casual-effects.com&#x2F;markdeep&#x2F;features.md.html?noforma...</a>) if the browser doesn&#x27;t support HTML.<p>Markdeep is good at progressively mixing HTML &amp; MD so you can choose how much of each to put in to your page. I use it for mostly MD + MathJax notes + some HTML&#x2F;JS&#x2F;SVG&#x2F;Canvas&#x2F;WebGL for when I want dynamic graphics in my notes.

It most certainly would not be a bad idea to have .md files render natively in a browser. Browsers also natively render images, videos, PDFs.<p>That said, the idea that this somehow changes any dynamic on the web are mere fantasies. The masses self-publish on social networks. On their phones. And not even that, as most largely lure.

HTML &#x2F; CSS ended up being extremely granular and hackable while missing the big building blocks that would have readily matched the structure of the web - things like navigation menus or page outlines. We waited over a decade for the layout systems to catch up to developer needs while creating buggy float-based grids. It&#x27;s an outlier that media queries were already in widespread availability when mobile really started picking up.

It&#x27;s been 10 years since Zed Shaw suggested a &lt;markdown&#x2F;&gt; tag.<p>clean speech warning: swearing. <a href="https:&#x2F;&#x2F;youtu.be&#x2F;_CEBG_s92P8?t=398" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;_CEBG_s92P8?t=398</a>

It&#x27;s already done in Gemini protocol with Gemtext format (<a href="https:&#x2F;&#x2F;gemini.circumlunar.space&#x2F;docs&#x2F;gemtext.gmi" rel="nofollow">https:&#x2F;&#x2F;gemini.circumlunar.space&#x2F;docs&#x2F;gemtext.gmi</a>)

The author is lying. The source isn&#x27;t actually a markdown document, the source is HTML (you can easily verify this by right-clicking and selecting &quot;View Source&quot;)<p>It&#x27;s actually quite easy to <i>actually</i> render markdown pages in a browser. Start with this:<p><pre><code> &lt;!doctype html&gt;&lt;meta charset=&quot;utf-8&quot;&gt;&lt;script src=&quot;notes-all.js&quot;&gt;&lt;&#x2F;script&gt;&lt;textarea&gt; ## MarkDown *HERE*!!!!! </code></pre> and &quot;notes-all.js&quot; contains something like this:<p><pre><code> document.write(&#x27;&lt;link rel=&quot;stylesheet&quot; href=&quot;css&#x2F;style.css&quot;&gt;&#x27;)); document.addEventListener(&#x27;DOMContentLoaded&#x27;, (event) =&gt; { var m = markdownIt({&#x27;html&#x27;: true, &#x27;linkify&#x27;: true}); var t = document.querySelector(&#x27;textarea&#x27;); var d = document.createElement(&#x27;div&#x27;); d.setAttribute(&#x27;id&#x27;, &#x27;content&#x27;); d.innerHTML = m.render(t.value); t.replaceWith(d); }); </code></pre> followed by markdown-it source code

I spend a good part of my week writing docs. The docs that come out of Markdown are hard to read, hard to maintain, long, ugly, and limited, requiring postprocessing for simple things like a Table of Contents. Websites need content to be even richer than docs (and no, Mr. Developer, what <i>you</i> want is not the sole requirement of the rest of the people on the planet). If you want to make an entire website out of Markdown, make Markdown suck less.<p>I think we need a configuration format for websites. Configuration formats are designed for humans first, and fit to purpose. What might that format require? Probably: style, layout, macros, emeddable objects, inheritable&#x2F;overrideable values, logic, loops, etc. Basically a DSL. You describe independent blocks (layout, style, content, etc) and the browser takes the instructions and renders the result. Not insanely different in concept than HTML&#x2F;CSS, but everything could use one common format, in a manner more human-friendly than we have now, content would be independent of form&#x2F;function, and none of it would inherit some unrelated design principles from some antiquated non-human-friendly technology.<p><pre><code> text &quot;Employees table description&quot; | This is a description of the employees table. The name and e-mail address are listed to the right. table &quot;Employees&quot; @Name ~&gt; Frank Suzanne Rahul Aman @E-mail address -&gt; frank@me.com suzanne@me.com rahul@me.com aman@me.com style &quot;table.Employees&quot; @Name column bgcolor &quot;green&quot; @&quot;Email address&quot; rows bgcolor &quot;gray&quot; layout &quot;main-page&quot; panel &quot;1&quot; align: left content &quot;text.Employees table description&quot; panel &quot;2&quot; align: right-of &quot;layout.main-page.1&quot; content &quot;table.Employees&quot;</code></pre>

The problem with only using markup to render websites is the lack of navigation.<p>We need something to show next&#x2F;previous page (we have rel headers and tags for that) and something that shows a tree navigation structure for populating menus (not sure what exists for that)<p>The tree structure would need to be “crawlable” because for very large sites, the entire tree can’t be loaded. That could be solved by representing nodes on the tree as URLs that can be loaded by the client as needed.<p>I’d love to see this happen. I don’t think we need markdown per-se… maybe it’s a subset of HTML that leaves out css, JavaScript, and a lot of the other nonsense.<p>Is anybody interested in building this out? I have ideas for the server and formats, but would want help implementing the clients.

We should have multiple formats besides HTML. In fact we already <i>do</i> have this, in the “Content-Type” response header, we just should use it more<p>Send data with Content-Type text&#x2F;json and Firefox will display a fancy JSON viewer, send data with text&#x2F;plain and Firefox displays plain text, pdf files, downloadable files, etc. Well, we can add text&#x2F;markdown where the browser automatically renders markdown files. And when the next HTML replacement comes out we can add that as well.<p>What about backwards compatibility? We already have that too: webservers can check the User-Agent request header, and return converted data for older browsers. Though we’d need a centralized database or fallback solution to support niche browsers…

That page has<p><pre><code> &lt;link rel=&quot;stylesheet&quot; href=&quot;&#x2F;katex.min.css&quot;&gt; &lt;script src=&quot;http:&#x2F;&#x2F;localhost:8888&quot;&gt;&lt;&#x2F;script&gt; </code></pre> The .css file doesn&#x27;t exist and what&#x27;s with the localhost access?

&gt; We really need a new publishing tool for everyone that doesn&#x27;t require intricate knowledge of how the entire web computing stack functions.<p>That tool is called HTML. It is usually supplemented by CSS. Every Markdown element has a one-to-one translation to it. This webpage is a particular stylesheet, plus basic HTML elements that you could write in &lt;&gt; style just as easily as you could write them in *_# style. If HTML requires particular defaults to look right, then that is a really great reason to fix the defaults, but not a really great reason to junk the whole thing and start over.<p>Markdown isn&#x27;t particularly good, it isn&#x27;t particularly standardized, and it isn&#x27;t even compatible with reader mode (e.g. images). Just write HTML. Browser standards have not <i>degraded</i> to the point that you need to write a web page differently than people wrote them fifteen years ago for it to look the same; a toolbox with a million complicated tools and one obvious screwdriver is not a toolbox that makes it very hard to unscrew screws.<p><a href="https:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;</a>

<p><pre><code> Thus, instead of - Fruits - apple - orange you must write - Fruits - apple - orange </code></pre> This is an obvious non-starter.<p>(edit)<p><pre><code> ...we allow headings to &quot;lazily&quot; span multiple lines: &gt; ## My excessively long section heading is too &gt; long to fit on one line. </code></pre> What?<p><pre><code> ...if you open a code span and don&#x27;t close it, it extends to the end of the paragraph. That is similar to the way fenced code blocks work in commonmark. &gt; This is `inline code. </code></pre> Is this a joke?

I&#x27;ve been using Hugo to translate Markdown into my static site, and I&#x27;ve been extremely happy with it.

My personal take is that markdown is only good when you can customize it to your needs and situation. There are a million markdown flavours, because everyone who ever implements it decides to add their own extensions to it to suit their situation. There have been attempts at creating a single unified standard, but these miss the point: if we wanted a single shared syntax, we could use html directly; the advantage of markdown(s) is that it lets you create something that looks clean and simple as plain text, while turning into a nicely marked-up document. A &quot;standard&quot; markdown would need to have a &quot;standard&quot; extension mecahnism (or none at all...) which would inevitably look like ass for most use cases.<p>I nowadays usually just write html directly for my personal documents, because I spent long enough messing around with markdown parsers trying to get them to act how I want. But for a website commenting system (eg), it makes sense to spend some time making the formatting system nice to use, which involves customizing your flavour of markdown. I don&#x27;t think web browsers can or should try to do a good job of this; it requires to many specialized demands for them to be able to create a generic solution. If you want to write in markdown, its easy enough nowadays to format it on the server, or client side with a small js snippet.

It&#x27;s said that the father of LISP, John McCarthy, lamented the W3C&#x27;s choice of SGML as the basis for HTML : « An environment where the markup, styling and scripting is all s-expression based would be nice. » The {lambda way} project could be an answer, small and simple: <a href="http:&#x2F;&#x2F;lambdaway.free.fr&#x2F;lambdawalks&#x2F;" rel="nofollow">http:&#x2F;&#x2F;lambdaway.free.fr&#x2F;lambdawalks&#x2F;</a><p>In lambdatalk such a HTML code<p><pre><code> &lt;h1&gt;Page Title&lt;&#x2F;h1&gt; &lt;p&gt;Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut ac lorem ut massa euismod vestibulum. &lt;p&gt;Nullam rutrum blandit eleifend. Aenean a varius diam. Morbi sodales velit nunc, vel vestibulum lorem tempus sodales. </code></pre> is written like this<p><pre><code> _h1 Page Title _p Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut ac lorem ut massa euismod vestibulum. _p Nullam rutrum blandit eleifend. Aenean a varius diam. Morbi sodales velit nunc, vel vestibulum lorem tempus sodales. </code></pre> And you can also compute 3x4 writing {x 3 4} or compute the factorial of 100, compute a Fast Fourier Transform, draw complex graphics, ... it&#x27;s a true programming language with a coherent syntax, unlike Markdown.

As a compromise, might I suggest:<p><pre><code> &lt;markdown class=&quot;commonmark&quot;&gt; &lt;![CDATA[ # It&#x27;s Markdown! Sure _is_ ]]&gt; &lt;&#x2F;markdown&gt;</code></pre>

OMG, no.<p>We need to bring text editing into the 21st century where rich text is standardized across all platforms and devices. We can send multicolored emoji to just about any device on the planet, but we still can&#x27;t bold, italicize, underline or color basic text. It&#x27;s straight up insane.<p>Think about it: <i>There is no such thing as &quot;plain text&quot;, it&#x27;s just encoding we don&#x27;t see.</i><p>Even if you&#x27;re a die-hard keyboard jockey, unless you&#x27;re looking at your command line and mentally parsing raw ANSI encoding like \e[1mBold, you&#x27;re not using &quot;plain text&quot;. There&#x27;s tons of encoding underneath every text editor and terminal program, you just don&#x27;t see it. We already have a standard encoding for rich-text, we need to start using it. It&#x27;s called HTML, and every device with a screen on the planet knows how to display it. We just need to <i>hide</i> the tags everyone bitches about just like vi hides a highlighted line&#x27;s \e[43mYellow codes. We should never need to see it.<p>Any place we&#x27;re able to enter text should support rich text, from boot up screen through to apps. And underneath it should all be HTML. It&#x27;s like the display compositor on macOS. None of us think about the fact it uses PDF under the hood, right? We&#x27;re not debating whether it should be done using SVG. It&#x27;s invisible. This debate should have been settled decades ago.<p>I&#x27;ve been writing about this in detail for the past several weeks. I swear the tech industry has lost its collective minds. At this point I&#x27;m truly wondering if Markdown is some sort of cult. We need to kill these lightweight markup formats with extreme prejudice and start solving the real problem.

One could use Apache2 .htaccess to set up a directory header&#x2F;footer which load a script (hidden from listing in .htaccess) which parses a .md file listing into a list of articles, and fetches a couple of the first ones as a front page. Then just use a URL fragment to track which article is open, and fetch &amp; render that article’s markdown fully onto the page.<p>Disable JS and you have a list of markdown files. Enable JS and get a website.

I like Markdown and use it at work, but I think Asciidoc is a better markup language because it is more consistent and has support for more things than Markdown does (e.g., better table support, callouts, tips, etc.).<p>I currently use 11ty with the Asciidoc plugin for building websites. This setup is nice because I only have to fiddle with HTML and CSS during the design phase. Once that&#x27;s done, nearly all my website maintenance is done in Asciidoc. Easy!<p>I don&#x27;t think I&#x27;d want to directly write an entire website in either Markdown or Asciidoc. I think, eventually, doing so would result in these markup languages becoming as cluttered and weird as the HTML&#x2F;DOM&#x2F;JavaScript&#x2F;CSS mess is now.<p>I think a better step to improving HTML and CSS would be to have the browsers support Slim (<a href="https:&#x2F;&#x2F;github.com&#x2F;deepin-community&#x2F;ruby-slim" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;deepin-community&#x2F;ruby-slim</a>) and Sass out of the box instead. That would make my design phase less wordy and redundant while keeping my Asciidoc experience nice and tidy.

I agree that we should have some diversity in our rich text terminal systems, however I think that markdown is significantly close to the tree(html) that it does not matter much, my candidate is postscript. this is only half a joke, What I would really like to see is diversity in our client side scripting system.<p>The elevator proposal goes something like this. restructure the browser to expose a virtual machine, then let us do things like (script lang=&quot;<a href="https:&#x2F;&#x2F;gcc.org&#x2F;gcc8&quot;)...(&#x2F;script)" rel="nofollow">https:&#x2F;&#x2F;gcc.org&#x2F;gcc8&quot;)...(&#x2F;script)</a> or (script lang=&quot;<a href="https:&#x2F;&#x2F;rust-lang.org&#x2F;165&#x2F;wvm" rel="nofollow">https:&#x2F;&#x2F;rust-lang.org&#x2F;165&#x2F;wvm</a>&quot;) or lang=&quot;<a href="https:&#x2F;&#x2F;python.org&#x2F;11&#x2F;wvm" rel="nofollow">https:&#x2F;&#x2F;python.org&#x2F;11&#x2F;wvm</a>&quot;, etc, etc. The way we are stuck on javascript is kind of sad.

This convo reminds me of MDX -- <a href="https:&#x2F;&#x2F;mdxjs.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;mdxjs.com&#x2F;</a> -- allows you to mix JSX with markdown, popular for making documentation pages for design systems.<p>A lot of the limitations of MD mentioned here are alleviated by allowing arbitrary JSX, which of course is optional for users who want something more basic.

No, why should we do that? Markdown websites just to render it BACK into HTML? That&#x27;s not the browser&#x27;s job.<p>The issue is, Markdown is nice because of its simplicity. The minute you start making it standard and widespread... feature-creep will happen and MD will just have as much noise as HTML does now.

There’s prose.io which basically does this<p><a href="http:&#x2F;&#x2F;prose.io&#x2F;" rel="nofollow">http:&#x2F;&#x2F;prose.io&#x2F;</a>

The article should probably read: we should write more simple websites. A few lines of css does the trick, usually. That&#x27;s what I do in my tiny website <a href="http:&#x2F;&#x2F;scriptkid.it" rel="nofollow">http:&#x2F;&#x2F;scriptkid.it</a> I learned from someone who posted here on HN the &lt;p&gt; trick.

I see some people in multiple comments discussing the need for some sort of standard for markdown if it were to be used for (goals...).<p>Does nobody else remember the debacle and (limited) fight between Jeff Atwood and John Gruber (markdown&#x27;s creator) over this?<p>It was a big deal here, and of course, over at Coding Horror, Atwood&#x27;s blog. And the reason was: Atwood was calling for some kind of standard, and Gruber actively opposed the mere notion. Gruber claimed ambiguity was baked in in markdown and he didn&#x27;t want a standard. So take this into consideration before proposing some markdown standards committee: the creator of markdown has said he actively opposes this. I guess he can be bypassed, but what does it say about the future of said standard if the original author says &quot;no&quot;?

One thing that&#x27;s always been a source of a tension for me is how to handle navigating around a &quot;web of documents&quot;.<p>There are limits to what you can do with &quot;in-band&quot; links in the text before they get to be contrived, awkward, and non-discoverable.<p>Users seem to have a revealed preference for on-page links to barely-related URLs and want those links to have some spatial consistency over time. So that means adding some &quot;fluff&quot; (nowadays presumably nested in a &lt;navigation&gt; tag) to every document.<p>One past experiment with out-of-band navigation was framesets, but they had some significant issues (not least of which is that the URL pointed to a container rather than the contained document).<p>Are there some other interesting experiments with out-of-band navigation? Or is adding some semantic tags to HTML as good as it gets?

I&#x27;ve been debating on using Org Mode documents to render to HTML and serve those kind of static pages for a blog. I&#x27;ve heard of people doing something similar before (Org -&gt; HTML or Org -&gt; Md -&gt; HTML). But the other part of me wants my own NIHed, over-engineered solution :)

We already do. They use static site generators to produce HTML (a good interchange format) from a customized form of markdown (which is not standardized at all and very customizable). This state of the world is totally fine - it works well for both viewers and content producers.

With modern HTML it&#x27;s actually pretty easy to use markdown wherever you like. Though there is no built-in markdown element, they have built in the ability for authors to define custom elements. You can define your own custom &lt;mark-down&gt; element and put your mark down syntax inside and as it is, as source code it&#x27;s nice and human readable even if we didn&#x27;t do anything further. But we can also define how this element should render, and so it&#x27;s very straightforward work to wire up any existing &quot;markdown to HTML&quot; library in JavaScript to consume the markdown contents of the tag and display rendered HTML.<p>This is so easy to do, not just for markdown, but almost anything you could want to embed or work with in HTML.

Markdown came to be as input for generating HTML, so I don&#x27;t see why the suggestion is so controversial to some?<p><pre><code> https:&#x2F;&#x2F;daringfireball.net&#x2F;projects&#x2F;markdown&#x2F; </code></pre> Also, as already mentioned, Gemini protocol does exist.

Markdown by definition compiles to HTML and must be rendered by a browser as HTML. This seems to be a widely overlooked fact in this thread.<p>It&#x27;s fine to write MD, but know that it&#x27;s a limited and shortcut form for the real HTML that will be output and rendered.<p>The short form is great for short stuff but to access the full power of HTML and CSS takes really messy spaghetti MD. And don&#x27;t even start with JS or TS. Modern sites usually need code and that means web components and that means real HTML and all of CSS need to be present and accessible in an orthogonal way -- not some via MD syntax and some with HTML glommed-onto MD.

This reminded me that a long time ago I used S3 website&#x27;s error handling feature so that S3 could render simple markdown files as HTML natively: <a href="http:&#x2F;&#x2F;composedit.net&#x2F;" rel="nofollow">http:&#x2F;&#x2F;composedit.net&#x2F;</a><p><a href="http:&#x2F;&#x2F;composedit.net&#x2F;dickens" rel="nofollow">http:&#x2F;&#x2F;composedit.net&#x2F;dickens</a> is actually a 404 error that fetches <a href="http:&#x2F;&#x2F;composedit.net&#x2F;text&#x2F;dickens.md" rel="nofollow">http:&#x2F;&#x2F;composedit.net&#x2F;text&#x2F;dickens.md</a> and uses Javascript to render it. Unbelievably dumb but works. Serverless before there was serverless!

There&#x27;s Gopher, Gemini, a myriad of static site generators that render markdown...<p>I like the idea of my browser rendering markdown. But it&#x27;s not going to solve the problem, as long as the same client application that renders documents can also render web applications, people looking to bait you with a document into running software on your machine will just publish web applications with some text inside of interest to you. What&#x27;s needed is separate client software for running web applications and rendering documents, and a different protocol for each, where we fucked up was using http for everything.

Actually, there&#x27;s an app that does that : Joplin from <a href="https:&#x2F;&#x2F;github.com&#x2F;laurent22&#x2F;joplin" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;laurent22&#x2F;joplin</a><p>you can publicise the markdown text that you&#x27;re writing in markdown. here&#x27;s an example with my joplin server and with the desktop app running on linux. I get this link : <a href="https:&#x2F;&#x2F;joplin.mehdiguiraud.info&#x2F;shares&#x2F;8YBjIJwoNh15uVY900xqlR" rel="nofollow">https:&#x2F;&#x2F;joplin.mehdiguiraud.info&#x2F;shares&#x2F;8YBjIJwoNh15uVY900xq...</a>

The charm of markdown is there are different flavours, you pick your favourite, and it can evolve independently of the web itself. Making browsers render markdown means markdown needs a single standard, or a standard of specifying standards and some kind of document type declaration, agreement by WHATWG and so on! For what? There are a lot of web publishing platforms for non technical authors. Free and paid. There are also simple programs to turn markdown into HTML. Uploading, hosting, DNS are much bigger barriers than HTML syntax anyway.

Markdown could potentially replace HTML as a more succinct markup language but it&#x27;s not sufficient by itself because it has no way to represent styling and layout. You&#x27;d need to jam CSS into it somehow

We could just go back to HTML 1.0, which is roughly equivalent to Markdown.

Don&#x27;t forget that markup refers to the document&#x27;s formatting and markdown is a specific markup library that converts text-to-HTML. So technically all browsers do support markdown.<p>We should re-visit the actual term &quot;mark-up&quot; which refers to decorating copy during the editing phase. I think many people agree that using markdown to &quot;mark-up&quot; copy on websites is easier.<p><a href="https:&#x2F;&#x2F;daringfireball.net&#x2F;projects&#x2F;markdown&#x2F;" rel="nofollow">https:&#x2F;&#x2F;daringfireball.net&#x2F;projects&#x2F;markdown&#x2F;</a>

Markdown results in unintentional formatting more frequently than not in my experience, and it is this reason alone that I avoid it anywhere I have a choice to, including any software I implement.

Mandatory mention to Markdeep: <a href="https:&#x2F;&#x2F;casual-effects.com&#x2F;markdeep&#x2F;" rel="nofollow">https:&#x2F;&#x2F;casual-effects.com&#x2F;markdeep&#x2F;</a>

Once upon a time I made a very minimal PoC markdown &quot;browser&quot; in a day or two. It basically had a navigation bar like a browser, only displayed markdown and would only follow links to other markdown documents. It was more of a project to play with React Native for macOS&#x2F;Windows more than anything serious, but I think the general idea could be neat if implemented correctly in some native GUI toolkits.

I also ended up using Markdown to create a blogging platform[0] for my website. It has many benefits as it&#x27;s a popular format, so you can for example edit and see the result directly inside VSCode.<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;Cristy94&#x2F;markdown-blog" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Cristy94&#x2F;markdown-blog</a>

Can someone explain what is the point of ipfs? I visited the homepage and it mostly shows an information about what it is not and disadvantages of things that are not ipfs.<p>But I am struggling to understand why would I want to use it and how?<p>For instance, can I host a website on it? Can I put a wordpress on it? How can I share my website with someone? Can I use my own domain? Or is it like FTP? I really don&#x27;t get it and feels like I am missing out.

Agree with many folks here:<p>Markdown is not sufficient for the task of expressing the modern web.<p>All that said... We shouldn&#x27;t stop thinking of ways to reimagine what the WWW actually is.<p>Why not create a new web-browsery thing which uses a totally different language, totally different paradigm for composition, heck why not a totally different network transport?<p>If you think that sounds dumb...I just described the current state of Netflix.

Website is broken, but I infer from the comments that this would fit the bill:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;DannyBen&#x2F;madness&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;DannyBen&#x2F;madness&#x2F;</a><p>My company uses it internally for a load of things. I love writing in MD and pushing to gerrit and when it is submitted the change is live.

Yes, we should have open standards for content-types and dynamic fetching and updating of code from trusted locations on the network. Then the browser itself becomes little more than a container for executing rendering code, with plugins for every content-type under the sun. But we are on a different timeline.<p>With WASM, this may yet still happen.

&gt; &quot;towards a presentation-independent data format for text&quot;<p>Wikitext is more suitable than Markdown for this role though less ergonomic.<p><a href="https:&#x2F;&#x2F;www.mediawiki.org&#x2F;wiki&#x2F;Wikitext" rel="nofollow">https:&#x2F;&#x2F;www.mediawiki.org&#x2F;wiki&#x2F;Wikitext</a>

Something pretty similar already exists, and it&#x27;s free... Github pages can turn your markdown into a website, hosted for free: <a href="https:&#x2F;&#x2F;www.markdownguide.org&#x2F;tools&#x2F;github-pages&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.markdownguide.org&#x2F;tools&#x2F;github-pages&#x2F;</a>

Two problems:<p>Most people don&#x27;t want the simple websites you could render in basic Markdown, that&#x27;s why we don&#x27;t have more of them already. How many of the top 1000 websites are a column of text and nothing else?<p>If most people wanted simple websites, they would write them with a WYSIWYG editor, they would not learn Markdown.

If you&#x27;re interested in the history of why I wrote this article, then it originated from this Twitter thread: <a href="https:&#x2F;&#x2F;nitter.net&#x2F;timdaub&#x2F;status&#x2F;1590731949433573377" rel="nofollow">https:&#x2F;&#x2F;nitter.net&#x2F;timdaub&#x2F;status&#x2F;1590731949433573377</a>

Jekyll on GitHub Pages does exactly this.<p>I wrote a dynamic PHP markdown site thing years ago which I still use at work to host Markdown files: <a href="https:&#x2F;&#x2F;github.com&#x2F;superjamie&#x2F;emdee" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;superjamie&#x2F;emdee</a>

No we shouldn&#x27;t. Markdown is just a small representation of markup that gets transformed to HTML.

Disclaimer: I&#x27;m biased as I created Scroll, but I can say pretty objectively that at this point it&#x27;s far better than Markdown and the gap is only going to widen.<p>Try it out! <a href="https:&#x2F;&#x2F;scroll.pub&#x2F;" rel="nofollow">https:&#x2F;&#x2F;scroll.pub&#x2F;</a>

My personal website is done similarly. I built it on top of markdown and added my own shortcodes so I could add macros and custom plugins as I added.<p>The site code lives separate from the post, media, and general &#x27;content&#x27; and doesn&#x27;t care what content is provided.

You could presumably just add a single line of JS to a markdown file that would render it as HTML.

I mean rendering JSX would be incredible from a &#x27;I hate waiting for build&#x27; perspective<p>babel has a trick where you load their JS and mark your &lt;script type=&quot;text&#x2F;jsx&quot;&gt;, but it is slow AF<p>more generally, pluggable templating &#x2F; rendering engines would be neat

I built an ultralight markdown CMS with this philosophy in mind : <a href="https:&#x2F;&#x2F;github.com&#x2F;arnaudsm&#x2F;raito" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;arnaudsm&#x2F;raito</a><p>Just drop index.html on a static server, and it&#x27;s live.

While I consider it a bit unrealistic to follow this approach in a big style, I like the idea. However, I would suggest to use asciidoc instead, since markdown is a bit to constrained. For examples image captions or tables are not possible in markdown.

What happens currently if you send a file with content type text&#x2F;plain to a browser? If the browser would just render it (maybe in a monospace font), you&#x27;re already halfway there, without needing to embed a Markdown renderer in the browser.

One line website renderer with pandoc. Apply template.html to all <i>.md files in current folder.<p><pre><code> find . -maxdepth 1 -name \*md -exec sh -c &#x27;pandoc --quiet --template template.html &quot;$0&quot; -o ${0%.*}.html&#x27; {} \;</code></pre></i>

The majority of the content you read on the web is there to lure your retinas so the website can shove sponsored photons into them.<p>The goal of de-cluttered web is nice. But if clutter is even just a notch more profitable, that ain&#x27;t going to happen.

I&#x27;ve create a Hugo blog Template used to create a Hugo blog quickly:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;openpress&#x2F;easy-hugo-blog" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;openpress&#x2F;easy-hugo-blog</a>

why not OrgMode websites? it handles tables too!

I had similar idea and created MDwiki in 2013 (now unmaintained): <a href="https:&#x2F;&#x2F;dynalon.github.io&#x2F;mdwiki&#x2F;#!index.md" rel="nofollow">https:&#x2F;&#x2F;dynalon.github.io&#x2F;mdwiki&#x2F;#!index.md</a>

What we (I) need is a simple product flow from Word (the corporate writer of choice) to HTML (the lingo of the web). I thought Markdown might get into Word somehow as an export option (without plugins) but sadly not.

I love using vitepress, <a href="https:&#x2F;&#x2F;vitepress.vuejs.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;vitepress.vuejs.org&#x2F;</a> Simplification of web development letting the main focus be on content and style.

... so that in 10 years Markdown will become the same clusterf*ck as HTML is today

Recently there was a thread about GitHub Blocks, interactive elements within READMEs and Markdown files in general. If we could standardize that and support it, that would be cool.<p>Also, isn&#x27;t this basically what HTML does anyway?

Why not simply use text&#x2F;plain content type when going fully minimal?

Reminds me of some related ideas I had: <a href="https:&#x2F;&#x2F;github.com&#x2F;runvnc&#x2F;tersenet" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;runvnc&#x2F;tersenet</a>

I would love to use more markdown but I need multidimensional layouts decided by the author (variable columns with text and images) and I haven&#x27;t seen anything like this.

I thought the real purpose of markdown was to let your users use HTML on your site but without the security risks of letting them use &#x27;pure&#x27; HTML.

YES THIS IS MY MOMENT!!<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33505339" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33505339</a>

We already have HTML<p>What we have done to it it&#x27;s a different matter.<p>Btw, which flavor of Markdown?<p>&quot;and if I want to do..?&quot;™ Don&#x27;t we&#x27;ll end up with an HTML without angle brackets?

I don&#x27;t think markdown is simple for those don&#x27;t know any tech. Those who can write markdown can set up Hugo, Jekyll, Hexo well.

Markdown having *italics* _italics_ **bold** __bold__ instead of _italics_ *bold* was such a mistake.<p>No idea how non-technical people were ever supposed to grasp that.

So, <a href="https:&#x2F;&#x2F;casual-effects.com&#x2F;markdeep&#x2F;" rel="nofollow">https:&#x2F;&#x2F;casual-effects.com&#x2F;markdeep&#x2F;</a> ?

Adding a markdown handler to a web browser should be pretty trivial, and that&#x27;s probably why it makes little sense to do it.

What you are describing is a technical solution to a business and social problem. It won’t actually solve what you think it will.

Screw that I want C++ rendered websites.

I wonder why nobody has created a netflix based on Torrent search.

I hate markdown. Try to find a list of supported syntax highlighting for code blocks.

Just use a Markdown-based CMS like Pico. Free, open-source, and uses Twig templating.

This is a great idea. First browser that implements this natively gets my vote!

Wasn&#x27;t this the whole point of the XHTML push back in like 2009?

Me buying the domain name react-markdown.com and the github repo &quot;react-markdown&quot;<p>...<p>PROFIT !!!

I would like Markdown encoded as s-expressions... but watchagonnado

I think the problem is correct, but the solution of markdown is not.

i made <a href="https:&#x2F;&#x2F;aiqc.io" rel="nofollow">https:&#x2F;&#x2F;aiqc.io</a> with readthedocs&#x2F;sphinx, but wound up doing most pages in html anyways

Functionally this seems like reinventing RSS.<p>And I’d say it’s about time.

Feasible only if md is a totally specified format.

I love this idea. Hope it gets some traction!

Or browser just renders markdown directly.

er if we are talking about creating documents without CSS and JS, HTML is way better than Markdown

Docsify already does this.

I get a 429 error.

I&#x27;ve seen a few people on here recommending everything from &quot;just use HTML&quot; (which misses the point) to &quot;just use Gemini&quot; (which misses the point even more).<p>Why not HTML? Why not Markdown? They aren&#x27;t self-contained.<p>* A web page written in either format can leak your IP address to external bad actors because of the way inline images work.<p>* Loading resources from more than one server is a reliability and security problem, and it performs bad on initial load (it&#x27;s great for subsequent loads, since external resources can be cached, but initial load time is bad and tech designers should really spend more time thinking about worst-case perf than about average-case).<p>* Downloading a web page is overly complicated. I should be able to download a page to my computer and never have to worry about the origin server going away, and that&#x27;s not possible on the HTML5 web. This is one of the main reasons for the enduring popularity of PDF. IPFS, in particular, would benefit from a self-contained document format, because it needs to know the full set of dependencies in order to pin a page as a whole, and ensure that you don&#x27;t accidentally pin an HTML file without pinning its images and wind up with a broken site.<p>Sure, you can make HTML pages that are self-contained, but because they aren&#x27;t always, people don&#x27;t build workflows around them.<p>Why not Gemtext&#x2F;Gemini?<p>* Nobody but nostalgic nerds cares about simplicity of implementation. I mean, come on, Markdown is even harder to parse than HTML is! Nostalgic nerds might be a worthwhile demographic to appeal to, but I think IPFS wants a wider audience than that.<p>* Inline images are not optional. Too many great creators with a lot of worthwhile things to say are either <i>creative artists</i> or <i>technical artists</i>. In the BBS era before inline images were practical, it didn&#x27;t stop people from drawing; they just relied in ANSI and ASCII art, and &quot;let&#x27;s go back to typewriter art&quot; only appeals to nostalgic nerds.<p>* And once you have inline images, you have to offer rich text layout features like tables, otherwise people will start posting pictures of text to work around your missing features (which <i>sucks</i> for either accessibility, because blind people can&#x27;t read them, or it sucks for simplicity, because deploying OCR is even more complicated than just offering decent text layout).<p>If I had to pick something? <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;EPUB" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;EPUB</a><p>* You can download an EPUB, and when the original host goes away, it still works! Pinning an EPUB in something like IPFS can work without requiring the CDN to know anything about the file format, since EPUBs are self-contained.<p>* Tooling already exists. It&#x27;s just XHTML in a ZIP file anyway, but there&#x27;s also EPUB-specific tooling (for example, the Texinfo release announcement a few days ago mentioned that you can export EPUBs from GNU info manuals).<p>* It supports text and image layouts that writers demand.<p>* There is one standard.

markdown is not a markup