Live data from Hacker News

We should have Markdown-rendered websites

ipfs.io

191–200 of 351 posts

Re: We should have Markdown-rendered websites

#191
post #188

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

Aside from perhaps images, I wish that browsers didn't try to render more complex content. I'd much rather be able to easily watch YouTube and embedded videos, for example, in an external player. And I've almost always ended up reopening PDFs in an external viewer, or configured the browser to do that by default where that option exists.

Maybe Markdown isn't as much of an issue as the videos and PDFs are, but it seems to me like it's better handled externally from the browser, or perhaps by an optional browser extension.

Re: We should have Markdown-rendered websites

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

Alphabet is a 1T USD market cap, I‘m confident they could finance implementing 3-5 flavors.

I don't think money is the problem.

It's the extra complexity to move markdown rendering from the control/responsibility of the server side, where it fits naturally, to the user-agent side, where it doesn't -- and for something that site publisher can already do (and evidently, rarely want to do).

Re: We should have Markdown-rendered websites

#193

Earlier quoted context omitted.

Markdown is undoubtedly more readable, but HTML can be more readable than most people make it. And considering that the ultimate goal is to wind up with a layed-out, styled document, its capabilities in that regard are just plain-old more important, especially since markdown isn't going to replace WYSIWYG editors any time soon, and almost everybody who needs to know HTML can learn it relatively easily. Browsers colla…

I may be that rare exception - a hobbyist developer who does design work as part of $dayjob.

I don't think that's as rare as people say, especially in smaller organizations.

Having an art school design education and a bit over a decade in (mostly back-end) web development, I've had plenty of deseloper type roles. If they fall under a design or marketing department, they'll spend 80% of the time doing design work and try to throw it together on some shitty wysiwyg monstrosity, ignoring performance, stability, maintainability, etc. If they fall under technical departments, design, ahem, decoration and polish is something to be applied at the end, if there's time, after the real work is done. Either way, having the same group of people responsible for two halves of that coin rarely yields a good balance, and they almost never pay any real attention to usability ... at least not for use cases that don't exactly mirror their own. Seems to me that replacing the flexibility of current markup and styling tools with simple markdown and reader-type layouts is just trying to apply the tech-focused solution to the entire problem the way Flash tried to do the opposite.

Re: We should have Markdown-rendered websites

#194
post #32

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.

So are Markdown rendering libraries entirely pointless? I'm not sure where you'd get the impression that HTML is a subset of HTML rather than Markdown being a superset of HTML. (even that is very reductive, though)

Re: We should have Markdown-rendered websites

#195
post #92

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

There is strapdown: https://github.com/chaitin/strapdown-zeta/blob/master/README...

``` Hello, Strapdown # title your awesome markdown content goes here... " rel="nofollow">http://cdn.ztx.io/strapdown/strapdown.min.js"> ```

Re: We should have Markdown-rendered websites

#196

Earlier quoted context omitted.

Self-containment is entirely unrelated to a format. You could do self-contained markdown, HTML or anything else if you wanted to.

Of course it's related to the format. Many formats, like PNG and Gemtext, are inherently self-contained, while other formats, like HTML and SVG, are not. Annoyingly, EPUB isn't inherently self-contained [1], but external access is explicitly optional [2], and it does make self-containment easier, because you can reuse resources across multiple pages, whereas HTML requires you to either duplicate the resources across…

> other formats, like HTML and SVG, are not.

You can mandate them to be if you are building something that uses them. If you don't have control, than its up to someone else to decide, and people wanted to be able to link remote resources.

Re: We should have Markdown-rendered websites

#197
We should have multiple formats besides HTML. In fact we already do have this, in the “Content-Type” response header, we just should use it more

Send data with Content-Type text/json and Firefox will display a fancy JSON viewer, send data with text/plain and Firefox displays plain text, pdf files, downloadable files, etc. Well, we can add text/markdown where the browser automatically renders markdown files. And when the next HTML replacement comes out we can add that as well.

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…

Re: We should have Markdown-rendered websites

#198
post #108

People are "big-picture" 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: HTML made the web easy to read. But you know what made the web easy to write? Facebook. Facebook was undeniably the technology that made it so that roughly everybody could write things on the web to be read by everyone. I really like the direction of this, because it point…

This is nonsense. There were tons of things that made the web easy to write before FB. That is not what made FB successful. It was a combination of a lot of little features plus the big innovation that your profile had to be your real life identity early on. That was the thing prior social networks didn't do. It enabled the uniquely Facebook experience of being able to find past friends and more distant family.

> the big innovation that your profile had to be your real life identity early on.

This came after facebook was wildly successful, so not early on. I also have never met a single person who was attracted by it, or was confused as to who their friends were before it existed. That being said, tying real names to online identity allowed facebook to buy data from brokers to fill out the sliced up audiences they sell to advertisers, so maybe it was important to their profitability.

What made FB successful was that it was a platform that other developers could program for, so it filled up with games and quizzes. Farmville, "Which Harry Potter Friends Spice Girl Are You?" etc. was all the edge that it took to kill myspace, a site which seemed to stop any sort of development about 10 minutes after launch.

But, as you say, even myspace made it very easy to write on the web. You could scribble on other people's "walls", put whatever you wanted on your own page, and every profile came with a blog.

Against what you say, however, is the timeline where you could just post random crap and all of your friends would see it and comment on it; the dopamine stream. There's no easier way to write than to spit out a random sentence or upload a random picture, and broadcast that instantly to hundreds of people.

Re: We should have Markdown-rendered websites

#199

Earlier quoted context omitted.

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.

Exactly this. I was paraphrasing the definition of source code from the GPL: "The source code for a work means the preferred form of the work for making modifications to it."

Re: We should have Markdown-rendered websites

#200

Earlier quoted context omitted.

> AsciiDoc is a plain text markup language for writing technical content. It’s packed with semantic elements and equipped with features to modularize and reuse content. Isn't that the opposite of Markdown?

It's basically a dsl to generate markdown. People who propose replacing markdown with AsciiDoc completely miss the point of Markdown in my opinion.

Asciidoc is not in any way a dsl to generate markdown. Being far more expressive than markdown would obviously prevent that.
Post reply on HN