Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Curse of Markdown

codehike.org

Post reply on HN
Print view View original

71–80 of 120 posts

Re: The Curse of Markdown

#71

Post by TheRealPomax »

bityard wrote: post #70
TheRealPomax wrote: post #38

Earlier quoted context omitted.

That sounds like a good idea, until you remember that there is no officially agreed upon markdown spec. For content authors it'd be both fantastic if browsers could just go "you guys go fight it out, we're just gonna go with GitHub flavored markdown" but at the same time for browser makers that's taking a position on something that they have no stake in. So writing or using someone else's custom element is pretty muc…

There is a Markdown spec: https://commonmark.org Although of course in practice, commonmark renderers are not plentiful or up to date. In my experience, most library authors end up just implementing the bits of Markdown they care about and the behavior they prefer for the ambiguous parts.

There are multiple markdown specs. This is one of them, probably the most well-known, but certainly not the only one.

Re: The Curse of Markdown

#72

Post by djbusby »

apitman wrote: post #60
kccqzy wrote: post #16

Markdown has always supported direct raw HTML in it. I don't see any gulf or sudden jump in cost. Don't be a Markdown purist. Even John Gruber, the creator of Markdown, is not a Markdown purist. Go look at the Markdown source of his blog and you will see that he frequently just uses raw HTML. He doesn't even do multi-paragraph ordered lists in Markdown, and chooses to write instead. And he also uses for clickable ima…

I wish more sites offered plain text versions. You can read mine with netcat: nc apitman.com 2052 <<< /txt/feed

On HTTP one can use the Accept header to indicate desired response type.

Re: The Curse of Markdown

#73

Post by rhdunn »

erickhill wrote: post #17
idlewords wrote: post #5

This format—with each paragraph fading as you scroll, and large changing images alongside—is borderline unreadable. Somewhat ironic in a blog post that (I think) is about tradeoffs between text and formatting.

It is so unnecessary and distracting. I quit reading after the first scroll as my eyes were pulled away from the text.

That's why I hate things like auto-rotating image/news carosels or Windows "live tiles". Having them manually triggered is fine but a) I may be half-way through reading a headline; and b) if I'm reading something off to the side it draws my eye for a moment, disrupting my workflow.

Re: The Curse of Markdown

#74

Post by rhdunn »

xscott wrote: post #36
idlewords wrote: post #5

This format—with each paragraph fading as you scroll, and large changing images alongside—is borderline unreadable. Somewhat ironic in a blog post that (I think) is about tradeoffs between text and formatting.

All that work to animate the little bits of data on the canvas, but greying the text was so irritating I closed the page. You don't realize how often your eyes jump back to previous sections until that ability is taken away from you. It seems like they wanted to make sure the reader knew which paragraph corresponded to the current version of the image/plot. Maybe they could've gotten the effect they were after by set…

Or even using the top as a kind of progress marker so you know where you are (or just reading from the middle of the page) only for the text to turn grey as you read it.

Re: The Curse of Markdown

#75

Post by apitman »

djbusby wrote: post #72
apitman wrote: post #60

Earlier quoted context omitted.

I wish more sites offered plain text versions. You can read mine with netcat: nc apitman.com 2052 <<< /txt/feed

On HTTP one can use the Accept header to indicate desired response type.

Sadly, content negotiation has fallen out of favor

Re: The Curse of Markdown

#76

Post by gherkinnn »

bee_rider wrote: post #42

> A great example of a rich content website is the Tailwind CSS landing page. This is a pretty bad example, right? It is the landing page for some web framework or whatever, that shows you it can make over-complicated websites by being itself an over-complicated website. It is being good at its job in some sense no matter what it does, because the thing it is showing is… the thing that it does. But, this doesn’t show…

Tailwind is a styling system. And it makes sense that its website shows off what it can do.

It has nothing to do with complicated.

Re: The Curse of Markdown

#77

Post by 0xbadcafebee »

Everyone else in the world - and I mean everyone - who is not a software engineer - does not use Markdown.

There is a reason for that. And it's not because they're all stupid and software engineers are all geniuses.

It's because normal people do not want to spend their day wasted in minutia, carving out huge chunks of technical jargon, just to get some words on a page to show up with a certain layout and format.

They want to highlight some text, and click the Bold button, or maybe Ctrl+B, and see the text become bold. They don't want to write code. They want to just make a fucking document, so they can get on with their day.

We have had programs that do this for about 40+ years now. They are called word processors and presentation tools. They work very well, and require absolutely zero code or weird characters.

But software engineers are so insanely out of touch, so cluelessly locked into their web browsers, that they literally cannot imagine a universe in which a person isn't writing code to get some text to show up on a screen, formatted and laid out.

It literally feels like everyone in this industry is insane.

Re: The Curse of Markdown

#78

Post by alsetmusic »

TheRealPomax wrote: post #71
bityard wrote: post #70

Earlier quoted context omitted.

There is a Markdown spec: https://commonmark.org Although of course in practice, commonmark renderers are not plentiful or up to date. In my experience, most library authors end up just implementing the bits of Markdown they care about and the behavior they prefer for the ambiguous parts.

There are multiple markdown specs. This is one of them, probably the most well-known, but certainly not the only one.

“This is my Markdown. There are many like it but this one is mine.”

Re: The Curse of Markdown

#79

Post by ModernMech »

flkiwi wrote: post #43

> Currently, these websites are outliers created by individuals who care deeply about the reader's experience or by companies willing to invest extra effort. We need more of them. The premise is deeply flawed. Richness is not a sign of care or investment in the reader's experience. Often it's exactly the opposite. Often richness is gaudy and pointless while simplicity makes content clearer and more useful. Maybe this…

Yup, the author's website is an example of this. Their flashy graphic that animated while scrolling did nothing for the content. In fact, their font was so small I could not read the text without zooming in, which completely contradicts the whole premise of the piece -- that a lack of "richness" is preventing ideas from being communicated. If richness prevents your ideas from being transmitted outright, then what's the point? If the author had used Markdown their idea would have been better communicated, but I guess that also would have contradicted it.

Re: The Curse of Markdown

#80

Post by wrboyce »

TheRealPomax wrote: post #71
bityard wrote: post #70

Earlier quoted context omitted.

There is a Markdown spec: https://commonmark.org Although of course in practice, commonmark renderers are not plentiful or up to date. In my experience, most library authors end up just implementing the bits of Markdown they care about and the behavior they prefer for the ambiguous parts.

There are multiple markdown specs. This is one of them, probably the most well-known, but certainly not the only one.

Obligatory https://xkcd.com/927/
Post reply on HN