Live data from Hacker News

We should have Markdown-rendered websites

ipfs.io

211–220 of 351 posts

Re: We should have Markdown-rendered websites

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

For people considering adding Markdown support to web browsers or other publishing tools, please consider adopting Djot instead: https://github.com/jgm/djot

It's very similar to the Markdown syntax we all know and love/hate, but fixes many inconsistencies in the spec, and also makes it possible to parse a document in linear time, with no backtracking. It is also much fuller-featured than commonmark, with support for definition lists, footnotes, tables, several new kinds of inline formatting (insert, delete, highlight, superscript, subscript), math, smart punctuation, attributes that can be applied to any element, and generic containers for block-level, inline-level, and raw content.

Some examples, showing how Djot would be rendered into HTML: https://htmlpreview.github.io/?https://github.com/jgm/djot/b...

Re: We should have Markdown-rendered websites

#213
One thing that's always been a source of a tension for me is how to handle navigating around a "web of documents".

There are limits to what you can do with "in-band" links in the text before they get to be contrived, awkward, and non-discoverable.

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 "fluff" (nowadays presumably nested in a tag) to every document.

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

Are there some other interesting experiments with out-of-band navigation? Or is adding some semantic tags to HTML as good as it gets?

Re: We should have Markdown-rendered websites

#215
post #5

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

Many Markdown dialects are adopting YAML metadata, so why not start a file with (for example) --- Dialect: GFM ---

That's what I do at taoofmac.com internally. The whole thing is a mix of Textile, Markdown and HTML

Re: We should have Markdown-rendered websites

#216
post #35

Gemini. You're describing Gemini. https://gemini.circumlunar.space/

Gemtext is a bit less capable than markdown, isn't it? IE there's no inline images.

There are, but the markup is too simple and too "pure" to be useful in any meaningful way.

Re: We should have Markdown-rendered websites

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

No, you're misunderstanding the difference between "what you believe to be easy" and "what actually was easy."

Popularity is better objective proof. You believe that a text box was easy, but still, people weren't using it.

Facebook is actually what got used.

Re: We should have Markdown-rendered websites

#218
With modern HTML it'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 element and put your mark down syntax inside and as it is, as source code it's nice and human readable even if we didn't do anything further. But we can also define how this element should render, and so it's very straightforward work to wire up any existing "markdown to HTML" library in JavaScript to consume the markdown contents of the tag and display rendered HTML.

This is so easy to do, not just for markdown, but almost anything you could want to embed or work with in HTML.

Re: We should have Markdown-rendered websites

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

This isn't an unknowable hypothetical. No need to presume anything. Markdown found in the wild is a mess. The GitHub Flavored Markdown renderer even encourages it.

Re: We should have Markdown-rendered websites

#220
post #120

Earlier quoted context omitted.

Interestingly, your comment is very similar to the Gemini FAQ "2.9 Why didn't you just use Markdown instead of defining text/gemini?" [1] [1] https://gemini.circumlunar.space/docs/faq.gmi

https://xkcd.com/927/

This xkcd is always posted when anything related to a standard is mentioned, but almost never in response to a standard that was actually created to unify all standards in its space.
Post reply on HN