Live data from Hacker News

We should have Markdown-rendered websites

ipfs.io

151–160 of 351 posts

Re: We should have Markdown-rendered websites

#151

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

The amusing thing is, that's what his Markdown translator is doing. Look at the page source. There's a fixed CSS preamble, and then there's very basic HTML 1.0:

    
    Why We Should Have Markdown Rendered Websites
    

You're viewing this document in your HTML-rendering browser but its source is actually a markdown file.

...
// file: http://home.md

    [home](http://home.md) [about](http://about.md)

    this my homepage

    // file: http://about.md

    [home](http://home.md) [about](http://about.md)

    this my about page
    
...

Best, Tim Daubenschütz tim@daubenschuetz.de

References 1: https://gist.github.com/JoeyBurzynski/617fb6201335779f8424ad9528b72c41
That's it. That's his HTML. You could write that by hand.

Re: We should have Markdown-rendered websites

#152
post #103

Earlier quoted context omitted.

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

Markdown is supposed to (be able to) look good as-is. Most people's Markdown doesn't look good as-is, though. They target the GitHub renderer and come from the GitHub-listing-as-a-product-landing-page school of thought, so even project READMEs are generally a mess.

Presumably if you want to "distribute digital artifacts in the format that is most useful for editing or creating derivative works", like parent said, you would make it look good.

Re: We should have Markdown-rendered websites

#153
post #70

Markdown is a convenient but deeply limited markup language with only a small subset of html's features. And yes, limitations are good because we want documents not web apps, etc, etc, but I mean "images can't have captions" limited, "navigation bars don't exist" limited. Actual important features of html don't exist in markdown, which is why almost every markdown platform ends up adding extensions and shortcodes. Wh…

The fatal flaw of HTML (and XML for that matter) is that the tags have the same visual weight as the text they're delimiting, which makes for a sense of clutter even in your minimal example. Markdown really scores here, by having a pleasing plain text representation as a goal from the outset, and I've love to see it used more widely for web pages. I'd also love to see it more widely used for offline reading, too - th…

> tags have the same visual weight as the text they're delimiting

IMO this issue should and can be easily solved by editor/viewer by rendering tags with lower contrast.

Re: We should have Markdown-rendered websites

#154

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 'pure' HTML.

There are some of us that think Markdown should be like this but it isn't. There are implementations in some languages that auto-escape any embedded HTML in a Markdown document, but for others they pass through.

That makes Markdown great for content when the authors and system owners are the same people. Not so great for content submissions from anonymous and potentially hostile third parties.

The project I originally had in mind for learning Elixir would have been Markdown based but there is no flag for disabling inline HTML in the current parsers and writing my own seemed like a bridge too far.

Re: We should have Markdown-rendered websites

#155
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…

> There are many flavors of markdown. We'd need a standards body, compatibility suites, etc., and for all the browser vendors to adopt it.

HTML has had the exact same problems.

You can say "CommonMark spec" and it's solved, isn't it?

Re: We should have Markdown-rendered websites

#156
post #114

Earlier quoted context omitted.

What technology IN REALITY, raw numbers, got more people to "type something into their computer for the purpose of multiple other people to read?" Facebook, and nothing else much comes close. (Again, I say this as someone who mostly hates it)

Now you're moving the goalpost. You originally implied FB making the web easy to write was the major innovation that lead to its success. I pointed out that simply giving people a dirt simple text box had been done many times before. There was nothing special about that part of FB. I am not dumb enough to argue that FB wasn't hugely successful, so your attempt to shift the argument away from your original point is si…

I have to agree with jrm4 - all the things you pointed out don't explain why FB groups and markets are so popular. There is also bunch of businesses that don't have their own website, just FB page - which is not comparable to "giving people simple text box".

It is simplified web experience from point of business owner, just drop logo, type in your company name and you have web presence - which happens to be where people are because they had friends/family there anyway.

Re: We should have Markdown-rendered websites

#157

Earlier quoted context omitted.

Plain HTML would be great, its just browsers holding it back. Without CSS, it looks unacceptably ugly.

just hit reader mode

My browser doesn't have one, and even if it did the point is that it should look good without any effort.

Re: We should have Markdown-rendered websites

#158
post #103

Earlier quoted context omitted.

Markdown is supposed to (be able to) look good as-is. Most people's Markdown doesn't look good as-is, though. They target the GitHub renderer and come from the GitHub-listing-as-a-product-landing-page school of thought, so even project READMEs are generally a mess.

Presumably if you want to "distribute digital artifacts in the format that is most useful for editing or creating derivative works", like parent said, you would make it look good.

That means you distribute the best you have. It doesn't obligate you to use better methods.

Re: We should have Markdown-rendered websites

#159
There's Gopher, Gemini, a myriad of static site generators that render markdown...

I like the idea of my browser rendering markdown. But it'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'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.

Re: We should have Markdown-rendered websites

#160
post #2

FWIW, just a couple of weeks ago we started doing that for a new sqlite subproject: https://sqlite.org/wasm 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.

When you say rendered on demand, you mean by the client, as in a page request? Why not just rerender to HTML on developer change? Genuinely curious why rendering on demand is preferred in this case.
Post reply on HN