Live data from Hacker News

We should have Markdown-rendered websites

ipfs.io

251–260 of 351 posts

Re: We should have Markdown-rendered websites

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

Write a list in HTML and write one in Markdown.

The difference in legibility is pronounced.

Especially if you don't want weird whitespace things.

Re: We should have Markdown-rendered websites

#252

Earlier quoted context omitted.

> Why didn't we end up with SGML -> XML "compilers"? We did; both the osx command-line tool of the venerable SP/OpenSP package, as well as sgmlproc (sgmljs) with output_format=xml does exactly that: output canonical XML markup with shortrefs resolved, omitted tags inferred, attribute values put in quotes and attribute names preprended where not already present, conditional marked sections included or omitted dependin…

Maybe I'm too young for all this, but that sure seems like something I've always wanted. Why aren't we using SGML for authoring HTML in 2022?

Because back in 1995 - 2005, getting a site up and running quickly was more important than doing it right.

Cue (and queue) endless kludges to re-do parts of SGML, badly.

Re: We should have Markdown-rendered websites

#253

Earlier quoted context omitted.

> Why didn't we end up with SGML -> XML "compilers"? We did; both the osx command-line tool of the venerable SP/OpenSP package, as well as sgmlproc (sgmljs) with output_format=xml does exactly that: output canonical XML markup with shortrefs resolved, omitted tags inferred, attribute values put in quotes and attribute names preprended where not already present, conditional marked sections included or omitted dependin…

Maybe I'm too young for all this, but that sure seems like something I've always wanted. Why aren't we using SGML for authoring HTML in 2022?

I was a big supporter of SGML-based languages: markup language written for humans to author.

However, the trend in computing in late 90s and early 2000s was to come up with more easily parsed languages, thus came things like XML: a mark-up language tuned for computers to produce.

But let's be honest here: parsing most XML can be done very simply, whereas supporting basic SGML was only possible with the OpenSP.

SGML is a specification of over 1000 pages of dense text, and that's before you get a language DTD on top of it (like the HTML or DocBook or TEI DTDs). Basically, it is too complex and too flexible, and it was too expensive to produce the tooling to support it (GUI editors, processing tools, making them performant...).

I mean, we are looking at MD here that is even less flexible than HTML: simplicity wins even if it only caters to 90% of the usecases!

Re: We should have Markdown-rendered websites

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

Write a list in HTML and write one in Markdown. The difference in legibility is pronounced. Especially if you don't want weird whitespace things.

But why does it matter what the underlying code looks like to the end user?

Nobody complains that the assembly code that runs their application is cluttered and illegible.

Re: We should have Markdown-rendered websites

#255
post #120

Earlier quoted context omitted.

https://xkcd.com/927/

https://timdaub.github.io/2022/08/28/six-unpopular-opinions-...

This fails to differentiate a "standard" from simply a "specification" (of a format, protocol, language...). I.e. we don't say "PostScript standard", but rather a "PostScript specification".

All of the claims they make apply to any specification, and yes, divergence is necessary to make progress.

A standard is a commonly agreed to specification, frequently ratified in one or another international organization (ISO, IETF, ECMA, W3C...). The main value of a standard is in ensuring interoperability where that matters more than all the other concerns raised.

Eg. we'd never have much of the internet if people didn't simply settle on the IP (v4) protocol.

Re: We should have Markdown-rendered websites

#256

Earlier quoted context omitted.

https://timdaub.github.io/2022/08/28/six-unpopular-opinions-...

This fails to differentiate a "standard" from simply a "specification" (of a format, protocol, language...). I.e. we don't say "PostScript standard", but rather a "PostScript specification". All of the claims they make apply to any specification, and yes, divergence is necessary to make progress. A standard is a commonly agreed to specification, frequently ratified in one or another international organization (ISO, I…

[deleted]

Re: We should have Markdown-rendered websites

#257
post #216

Earlier quoted context omitted.

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.

It’s great for journals and people that like to tinker with a simple spec.

I wrote a similar spec for lists: https://lists.sh/spec

The renderer is crazy simple when you can figure out the type by reading the first 4 chars of each line.

Re: We should have Markdown-rendered websites

#258
post #120

Earlier quoted context omitted.

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.

That's a pretty narrow reading of that XKCD: even the examples it gives are not the result of attempting to unify a set of standards.

Eg. AC chargers had a bunch of different, diverged "standards" for pretty much restricted use-cases (those 1.5mm x 4mm connectors and then micro- and mini-USB). Text encodings had multiple standards for encoding the same text (eg IBM, Windows code pages and ISO encodings) without unification attempts.

In both of these examples, there is one unifying standard added (USB-C and UTF-8 + Unicode) that did stop the proliferation of new standards.

But majority of things never result in one unifying standard that can do everything win: even SGML brough up in this discussion is an example. CORBA also springs to mind.

Re: We should have Markdown-rendered websites

#259

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://…

[deleted]

Re: We should have Markdown-rendered websites

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

Does nobody else remember the debacle and (limited) fight between Jeff Atwood and John Gruber (markdown's creator) over this?

It was a big deal here, and of course, over at Coding Horror, Atwood'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'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 "no"?

Post reply on HN