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

201–210 of 351 posts

Re: We should have Markdown-rendered websites

#201

Post by Beltalowda »

seized wrote: post #138
coldtea wrote: post #124

Earlier quoted context omitted.

> There are many flavors of markdown. We'd need a standards body, compatibility suites, etc., and for all the browser vendors to adopt it. Well, if it were to be adopted by vendors, the many flavors would be a non-problem. They can just agree on a flavor and be down with it. There's CommonMark anyway, they can just use that.

Except that CommonMark has its own very annoying things. Like loose lists. Multiple lists of bullet points ends up an ugly mess with CommonMark.

"I don't like this standard" is not the same as "there is no standard".

Re: We should have Markdown-rendered websites

#202

Post by acomjean »

bonestamp2 wrote: post #184
acomjean wrote: post #82

Earlier quoted context omitted.

I think this makes sense. Many of the GitHub readmes are in markdown already, so people are quite familiar with it and there might already be an open source package that renders it out…

In fact, github itself can already render it out. Markdown based websites hosted for free on github: https://www.markdownguide.org/tools/github-pages/

I guess it wasn't clear, but I meant those markdowns are rendered on everyones github page.. But the whole github pages thing is new to me. Very cool and seems like what the blog post was asking for.

Its using "Jekyll" to render those "github-pages" sites https://github.com/jekyll/jekyll

Re: We should have Markdown-rendered websites

#203

Post by iso1631 »

kridsdale2 wrote: post #190
robinsonb5 wrote: post #127

Earlier quoted context omitted.

The fatal flaw of HTML (and XML for that matter) is that the tags have the same visual weight as the text they're delimiting, which makes for a sense of clutter even in your minimal example. Markdown really scores here, by having a pleasing plain text representation as a goal from the outset, and I've love to see it used more widely for web pages. I'd also love to see it more widely used for offline reading, too - th…

IMO the main issue with writing HTML is it takes a two-armed key-chord to do a char.

Not entirely sure what you mean by "two-armed key-chord". It's shift-, or shift-. -- my keyboard's bottom line goes \ZXCVBNM,./. is right-index and right-pinky (as shift is so much wider)

Now sure, some are home row afficiandos, and having # on the home row is certainly beneficial to those as your right-index can stay on J as god intended

Or do you have a different keyboard layout to me. Keyboard layouts - especially the location of things like ,./?@;'#:@~[]{} vary a lot depending on the country you are in.

Re: We should have Markdown-rendered websites

#204

Post by bachmeier »

jerf wrote: post #167
bachmeier wrote: post #90

Earlier quoted context omitted.

After all these years, I still haven't found an important argument in favor of CommonMark. As I point out every time someone presents it as the answer, it doesn't handle things like math, so you still need to use unstandardized extensions, making the whole thing pointless.

The argument is that if you disqualify everything for not having $FEATURE, where $FEATURE varies from person to person, you have also essentially disqualified markdown entirely. As the saying goes, everyone uses only 10% of Microsoft Word, but everyone uses a different 10% of Microsoft Word. Much the same thing applies to this case for much the same reasons. If your standard is going to be "I want everything in any v…

> CommonMark is a decent solution to "I want to use Markdown", if you're willing to take the simplification.

It would be very hard to make a case for CommonMark over something like Pandoc markdown, given that it does so much more than CommonMark.

Note that the discussion here is markdown inside a browser. That's not a good place to go with a dramatic simplification.

Re: We should have Markdown-rendered websites

#205

Post by jerf »

bachmeier wrote: post #204
jerf wrote: post #167

Earlier quoted context omitted.

The argument is that if you disqualify everything for not having $FEATURE, where $FEATURE varies from person to person, you have also essentially disqualified markdown entirely. As the saying goes, everyone uses only 10% of Microsoft Word, but everyone uses a different 10% of Microsoft Word. Much the same thing applies to this case for much the same reasons. If your standard is going to be "I want everything in any v…

> CommonMark is a decent solution to "I want to use Markdown", if you're willing to take the simplification. It would be very hard to make a case for CommonMark over something like Pandoc markdown, given that it does so much more than CommonMark. Note that the discussion here is markdown inside a browser. That's not a good place to go with a dramatic simplification.

I feel like you read the quoted sentence and stopped. I talk about both the browser and simplification further on, literally the next sentence.

Re: We should have Markdown-rendered websites

#206

Post by LAC-Tech »

xigoi wrote: post #99
LAC-Tech wrote: post #93

Earlier quoted context omitted.

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

The whole point is that the client decides the presentation. If it wants to display images as inline, it will, if not, it won't.

Right, I guess the gemini browsers I tried did not display them inline.

Re: We should have Markdown-rendered websites

#207

Post by xigoi »

LAC-Tech wrote: post #206
xigoi wrote: post #99

Earlier quoted context omitted.

The whole point is that the client decides the presentation. If it wants to display images as inline, it will, if not, it won't.

Right, I guess the gemini browsers I tried did not display them inline.

I think Lagrange (the fanciest Gemini browser I know of) has the option to do that.

Re: We should have Markdown-rendered websites

#208

Post by tannhaeuser »

robinsonb5 wrote: post #127
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…

The fatal flaw of HTML (and XML for that matter) is that the tags have the same visual weight as the text they're delimiting, which makes for a sense of clutter even in your minimal example. Markdown really scores here, by having a pleasing plain text representation as a goal from the outset, and I've love to see it used more widely for web pages. I'd also love to see it more widely used for offline reading, too - th…

HTML is based on SGML, and SGML has short references to handle lightweight custom syntaxes. For example, you can define that an asterisk appearing in your content within a

element is replaced by , and moreover define that an asterisk appearing within content is replaced by , toggling emphasized text tags. So SGML very much acknowledges the need for lightweight markup, but the SHORTREF feature, like everything else requiring markup declarations, didn't make it into the XML subset of SGML.

HTML itself doesn't have these and other features (such as basic text macros) because SGML was understood to be available at least at authoring time.

Re: We should have Markdown-rendered websites

#209

Post by tomp »

The author is lying. The source isn't actually a markdown document, the source is HTML (you can easily verify this by right-clicking and selecting "View Source")

It's actually quite easy to actually render markdown pages in a browser. Start with this:

    
    ## MarkDown *HERE*!!!!!
and "notes-all.js" contains something like this:

    document.write(''));
    document.addEventListener('DOMContentLoaded', (event) => {
      var m = markdownIt({'html': true, 'linkify': true});
      var t = document.querySelector('textarea');
      var d = document.createElement('div');
      d.setAttribute('id', 'content');
      d.innerHTML = m.render(t.value);
      t.replaceWith(d);
    });
followed by markdown-it source code
Post reply on HN