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

241–250 of 351 posts

Re: We should have Markdown-rendered websites

#241

Post by Arainach »

vintagedave wrote: post #240
Arainach wrote: post #230

Earlier quoted context omitted.

The primary goal and appeal of Markdown is that it is easy to write . Optimizing for parsing is creating a fundamentally different product. Standardization of the spec is good. Requiring quirky behavior and blank lines that hurt reading is bad.

Looks like it simply makes Markdown easier for both computers and humans! I love this and can’t believe I haven’t seen it before. > Requiring quirky behavior and blank lines that hurt reading Really? The linked spec says, referring to a blank link in indented lists: > reStructuredText makes the same design decision. And as a design goal: > your document [must be] readable just as it is, without conversion to HTML and…

> reStructuredText makes the same design decision.

"This other product that doesn't understand the appeal of Markdown and also thought this was a technical problem rather than a user barrier to entry problem made the same mistake" is not exactly a strong defense.

> Sanity. Sanity introduced to an ambiguous spec. It’s wonderful.

Users don't care how hard or easy something is to parse. You write a parser once; you write Markdown millions of times.

> Looks like it simply makes Markdown easier for both computers and humans! I love this and can’t believe I haven’t seen it before.

Unfortunately it does not. This is less readable and more annoying to write:

>Markdown:

>- Fruits

> - apple

> - orange

>

>djot:

>- Fruits

>

> - apple

> - orange

These are fundamentally different products. If you want something easy to parse and human readable, use YAML. If you want something easy to write, use Markdown.

Re: We should have Markdown-rendered websites

#242

Post by vintagedave »

Arainach wrote: post #241
vintagedave wrote: post #240

Earlier quoted context omitted.

Looks like it simply makes Markdown easier for both computers and humans! I love this and can’t believe I haven’t seen it before. > Requiring quirky behavior and blank lines that hurt reading Really? The linked spec says, referring to a blank link in indented lists: > reStructuredText makes the same design decision. And as a design goal: > your document [must be] readable just as it is, without conversion to HTML and…

> reStructuredText makes the same design decision. "This other product that doesn't understand the appeal of Markdown and also thought this was a technical problem rather than a user barrier to entry problem made the same mistake" is not exactly a strong defense. > Sanity. Sanity introduced to an ambiguous spec. It’s wonderful. Users don't care how hard or easy something is to parse. You write a parser once; you writ…

I don’t mind pressing Enter twice instead of once.

I know that’s a glib answer. And I agree an extra line break should, to a human which reads indents, be unnecessary. But given the ambiguities of Markdown, something that is both human-readable and computer-readable is a huge advantage.

Also,

> Users don't care how hard or easy something is to parse

I don’t read it as about parsing. I read it as about writing. You can write one way and know exactly how it will be interpreted.

Re: We should have Markdown-rendered websites

#243

Post by nerdponx »

tannhaeuser wrote: post #239
nerdponx wrote: post #237

Earlier quoted context omitted.

Why didn't we end up with SGML -> XML "compilers"? As I understand it, XML is intended to be equivalent to SGML, with less syntactic flexibility to make it easier to parse. So once you've done the hard work of parsing SGML, it seems like it should be straightforward to emit the same data as XML for further machine processing. Or are there some SGML features that cannot be represented with an equivalent in XML?

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

Re: We should have Markdown-rendered websites

#245

Post by thrown_22 »

bccdee wrote: 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…

I've yet to have anyone explain why markdown with it's dozen flavours is better than HTML2: https://datatracker.ietf.org/doc/html/rfc1866

We broke a weird little markup language into something it was never meant to be because the last tower of crap got too high and collapsed on itself.

Now a webpage is html+css+javascript+a dozen frameworks. People are sick of it and want something better. Well HTML2 is better. Just HTML2, nothing else.

Re: We should have Markdown-rendered websites

#247

Post by thrown_22 »

timdaub wrote: post #31
hospadar wrote: post #26

I mean it _sounds_ good, but how will we cram a million ads down user's throats and measure every twitch of their input devices? It's almost as though the author is suggesting that web site proprietors might be more interested in "serving content" than "driving engagement" which I find disturbing and upsetting. /s

haha that's definitely a big component of it all. But the engaged clickable web is anyways dead. This post is a static HTML file hosted on IPFS with no back links to my carefully curated blog and media presence. No branding. It's because I've accepted that people's bullshit-radar is sensitive towards overly optimized engagement content. Rather I want my text to be read and those that care will anyways online-search m…

I think covid is when the internet jumped the shark for Joe Average.

You would get banned from twitter, facebook, reddit, instagram etc for saying what was official policy until _yesterday_. The sheer insanity of that policy left the terminally online in charge everywhere and the quality of every website suffered. If I look back to reddit posts which google still brings up more than half the people are banned. These are people who wrote thousand word replies to technical problems and were pillars of the community. The only ones left are the mentally ill unemployed since they are the only ones who have time to keep track of what is allowed there.

HN was headed down the same hole until that hilarious post by PG about heretics that got flagged for 8 hours. I imagine at that point it hit everyone in charge here that the people making the most noise were not their friends.

Re: We should have Markdown-rendered websites

#248

Post by syrrim »

My personal take is that markdown is only good when you can customize it to your needs and situation. There are a million markdown flavours, because everyone who ever implements it decides to add their own extensions to it to suit their situation. There have been attempts at creating a single unified standard, but these miss the point: if we wanted a single shared syntax, we could use html directly; the advantage of markdown(s) is that it lets you create something that looks clean and simple as plain text, while turning into a nicely marked-up document. A "standard" markdown would need to have a "standard" extension mecahnism (or none at all...) which would inevitably look like ass for most use cases.

I nowadays usually just write html directly for my personal documents, because I spent long enough messing around with markdown parsers trying to get them to act how I want. But for a website commenting system (eg), it makes sense to spend some time making the formatting system nice to use, which involves customizing your flavour of markdown. I don't think web browsers can or should try to do a good job of this; it requires to many specialized demands for them to be able to create a generic solution. If you want to write in markdown, its easy enough nowadays to format it on the server, or client side with a small js snippet.

Post reply on HN