Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We should have Markdown-rendered websites

ipfs.io

Post reply on HN
Print view View original

81–90 of 351 posts

Re: We should have Markdown-rendered websites

#81

Post by masswerk »

pocketarc wrote: post #61
graypegg wrote: post #46

Earlier quoted context omitted.

—I’d say it’s the other way around isn’t it? Wouldn’t Markdown be a subset of HTML, since all markdown can be expressed in HTML but not all HTML can be expressed in Markdown?— Edit: Markdown can contain HTML that gets meaningfully interpreted as markup as well. I’d also say HTML is not difficult to write, even for someone new to the concept. I don’t think anyone making their GeoCities homepage was too strained learni…

As far as I’m aware, you can write any HTML in Markdown, and it will be rendered normally. So Markdown can indeed contain any and all HTML. HTML can’t contain Markdown at all - a ### in HTML does nothing but a hello in Markdown does exactly what you expect it to.

To be fair, you can include Markdown inside script tags (assign a custom type like "text/markdown") and render this (the script's innerHTML) by another script.

Re: We should have Markdown-rendered websites

#82

Post by acomjean »

falcolas wrote: post #29
falcolas wrote: post #5

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

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…

Re: We should have Markdown-rendered websites

#83

Post by douglaswlance »

You already can render markdown. It shows as what it is: text.

If you want to render markdown as something else, you need to define what that other thing is. If you're suggesting we render it as a webpage, well webpages are made of HTML and CSS--so you're saying you want to render markdown as HTML/CSS.

We can already do that. There are a plethora of tools available to do that.

Re: We should have Markdown-rendered websites

#84

Post by notriddle »

I've seen a few people on here recommending everything from "just use HTML" (which misses the point) to "just use Gemini" (which misses the point even more).

Why not HTML? Why not Markdown? They aren't self-contained.

* A web page written in either format can leak your IP address to external bad actors because of the way inline images work.

* Loading resources from more than one server is a reliability and security problem, and it performs bad on initial load (it'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).

* 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'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't accidentally pin an HTML file without pinning its images and wind up with a broken site.

Sure, you can make HTML pages that are self-contained, but because they aren't always, people don't build workflows around them.

Why not Gemtext/Gemini?

* 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.

* Inline images are not optional. Too many great creators with a lot of worthwhile things to say are either creative artists or technical artists. In the BBS era before inline images were practical, it didn't stop people from drawing; they just relied in ANSI and ASCII art, and "let's go back to typewriter art" only appeals to nostalgic nerds.

* 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 sucks for either accessibility, because blind people can't read them, or it sucks for simplicity, because deploying OCR is even more complicated than just offering decent text layout).

If I had to pick something? https://en.wikipedia.org/wiki/EPUB

* 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.

* Tooling already exists. It's just XHTML in a ZIP file anyway, but there'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).

* It supports text and image layouts that writers demand.

* There is one standard.

Re: We should have Markdown-rendered websites

#85

Post by madeofpalk »

ElevenLathe wrote: post #71
jmull wrote: post #48

This doesn't really make sense, for a couple reasons... There are many flavors of markdown. We'd need a standards body, compatibility suites, etc., and for all the browser vendors to adopt it. Meanwhile, markdown is designed to transform to HTML, which browsers already render. Adding a markdown-to-html plugin/step to your web server or publishing process is not exactly the most burdensome thing, relative to everythin…

I get this, but OTOH it is IMO best to distribute digital artifacts in the format that is most useful for editing or creating derivative works. This is the free software philosophy but also a societal good. Many of us learned HTML and web technologies by reading the source code of websites, and we've closed that door behind us with all of the build steps that turn our actual code into a computer-readable-only mess wh…

you can distribute websites as markdown! Return markdown with a plain text content type and it'll show as markdown, which was designed to look good as-is and not require rendering to HTML

Re: We should have Markdown-rendered websites

#86

Post by isitmadeofglass »

buro9 wrote: post #32
graypegg wrote: post #20

HTML is already a markup language. You could just as easily make basic websites using HTML and some basic inline CSS. (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!) The problem is that people don’t make websites like that very often, e…

HTML is a subset of Markdown. You can include in Markdown any and all HTML. What Markdown provides here is an even lower barrier to entry for the majority of people... they just write text, learn a fraction more Markdown to so more... and if they want total control they eventually learn HTML too. It's not mutually exclusive... Markdown includes HTML.

> HTML is a subset of Markdown.

Yes, so all websites are already written in markdown. Its just tjat No browsers support the typical header/list shorthands, but that doesn’t matter because even if they did you’d still need more tages to get interactivity and styling working.

People aren’t imagining a world where markdown makes anything simpler they are imagino by that a format change would make people build less complex websites. But why would they? It’s not HTML that makes the Twitter front end or Facebook complicated, it’s the desisted functionality, which wouldn’t change even if the spice code looked more like markdown and less like html.

Re: We should have Markdown-rendered websites

#90

Post by bachmeier »

jerf wrote: post #37
falcolas wrote: post #5

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

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.
Post reply on HN