Live data from Hacker News

We should have Markdown-rendered websites

ipfs.io

291–300 of 351 posts

Re: We should have Markdown-rendered websites

#291
post #130

Earlier quoted context omitted.

Exactly what I was thinking, by omitting the and HTML can be quite concise [1]. Additionally the closing can be omitted from lists and barely a step over using - for bullet points. The worst part about HTML is the links, though. Anchor tags are awful. Having to repeatedly type and closing with is wayyy too boilerplate much for for something that is simply surrounded with [square](brackets) in markdown. [1] I go to ht…

I have the opposite problem. HTML links are consistent with the rest of the language. Something makes the same kind of sense as something . But markdown? I'm always forgetting the order of the (link)[text] or [link](text) or [text](link) or (text)[link]. It's just something that's invented, and not consistent with the rest of itself.

And, for the specific syntax: parentheses to surround the URL is jut bad because parentheses are URL code points, so you can’t just insert regular serialised URLs in Markdown in all cases. (See https://news.ycombinator.com/item?id=33340097 for more explanation.)

Re: We should have Markdown-rendered websites

#292
The charm of markdown is there are different flavours, you pick your favourite, and it can evolve independently of the web itself. Making browsers render markdown means markdown needs a single standard, or a standard of specifying standards and some kind of document type declaration, agreement by WHATWG and so on! For what? There are a lot of web publishing platforms for non technical authors. Free and paid. There are also simple programs to turn markdown into HTML. Uploading, hosting, DNS are much bigger barriers than HTML syntax anyway.

Re: We should have Markdown-rendered websites

#293
post #222
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…

> markdown is designed to transform to HTML Is it though?

>Markdown is a text-to-HTML conversion tool for web writers. Markdown allows you to write using an easy-to-read, easy-to-write plain text format, then convert it to structurally valid XHTML (or HTML).

From 2004

https://daringfireball.net/projects/markdown/

Re: We should have Markdown-rendered websites

#294
post #272
post #192

Earlier quoted context omitted.

I don't think money is the problem. It's the extra complexity to move markdown rendering from the control/responsibility of the server side, where it fits naturally, to the user-agent side, where it doesn't -- and for something that site publisher can already do (and evidently, rarely want to do).

I don't know why you say it doesn't fit naturally for the client to render a markup format. (With an RFC [0], too) Chances are your client already handles a bunch other than HTML like SVG. Or even contextual ones like WebVTT. [0] https://www.rfc-editor.org/rfc/rfc7763.html

> With an RFC, too

RFC 7763 does not define Markdown in any way. It acknowledges both the popularity and messiness of the Markdown family of syntaxes, registers a so-broad-as-to-be-nearly-useless media type for the family, and establishes a registry of variants (https://www.iana.org/assignments/markdown-variants/markdown-...).

Critically here, it does not recognise Markdown as a usable markup format in its own right. Only as a family of often ill-defined syntaxes that may be tolerably readable in raw form, and with the correct, unspecified tools may be converted to a formal markup language like HTML.

“Markdown” is utterly unsuitable as a publishing format. It’s designed as a writing format.

Re: We should have Markdown-rendered websites

#295
post #281
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…

Uh, yeah, that's a valid web-page, but I don't see how that counters "html is cluttered" statement. This is cluttered. It… just is. I know some people who suffered some mind deformation in academia and now claim LaTeX is the perfect markup for blogs, but I don't think I've encountered the same for html until now. I mean, does somebody really compose text in html?! Markdown is deeply limited, that's true, but I often…

> I mean, does somebody really compose text in html?!

Yes.

I use HTML the way people use markdown: as an open, easy to read, easy to write, plain text format for taking notes, writing articles, etc.

I find this quite intuitive and easy – partly because I’m an old-school web-developer from days of yore and I have HTML deeply internalised; partly because I use the abbreviated version of HTML noted above; and partly because I use a VIM plugin called Emmet which allows you to construct complex HTML fragments with a basic shorthand.

The reason why I use HTML instead of markdown is threefold.

* The first is that simple HTML, written with a little care, is readable as-is, and requires no transformation to see it looking pretty (just open in a browser). Markdown requires pandoc to turn it into something else.

* The second is that it is a semantically rich language, full of useful tags for expressing document structure and context for words and sentences. I find Markdown really confining.

* The third reason is that, if I take the care to fill in the basic author/keyword/desc meta-tags I can run scripts over my directories looking for and indexing things. Who cares Search Engines don’t use some of those tags anymore. I do.

Possibly they’re not entirely compelling reasons for anyone else to adopt HTML over markdown, but they work for me.

Re: We should have Markdown-rendered websites

#296
I agree that we should have some diversity in our rich text terminal systems, however I think that markdown is significantly close to the tree(html) that it does not matter much, my candidate is postscript. this is only half a joke, What I would really like to see is diversity in our client side scripting system.

The elevator proposal goes something like this. restructure the browser to expose a virtual machine, then let us do things like (script lang="https://gcc.org/gcc8")...(/script) or (script lang="https://rust-lang.org/165/wvm") or lang="https://python.org/11/wvm", etc, etc. The way we are stuck on javascript is kind of sad.

Re: We should have Markdown-rendered websites

#297

If Google upranked “documents” (simple HTML content without JavaScript), then there would be an incentive to publish simple content. Instead Google goes to insane lengths to parse JavaScript generated abominations, and otherwise allow/encourage shitty content.

Which search engines do not execute JavaScript codes?

I last paid active attention to this in mid-2017. At that time, Google mostly, eventually executed JavaScript, but it would often be weeks after initial indexing that any JavaScript execution happened; and there were rumours but scarcely more that Bing could execute JavaScript; and I know of no other engine doing any JavaScript. By mid-2018, Bing definitely sometimes did some JavaScript execution (see https://www.screamingfrog.co.uk/bing-javascript/). It’s probable things have become a bit more consistent by now, but actually loading pages realistically is so much more expensive than just parsing the initial serialised HTML that I think you can reasonably expect JavaScript-execution to be less consistent and reliable as they will very probably continue to prefer to avoid loading things that way if it’s not obviously required.

Re: We should have Markdown-rendered websites

#298

Markdown having *italics* _italics_ **bold** __bold__ instead of _italics_ *bold* was such a mistake. No idea how non-technical people were ever supposed to grasp that.

My observation of English-language typewriter and early plain-text computer usage (documents and emails) is that * was mostly used as equivalent to italics, ** and *** for stronger emphasis were not particularly uncommon (bearing in mind that traditionally there was simply no such thing as bold). But _ was kind of a historical oddity, with underlining used in lieu of italics in the typewriter era for technical reasons, implemented by means of overwriting; underscore-surrounding came much later, and never seemed particularly popular to me, and was more often interpreted as underlining rather than as italics—though the typewriter remarks are certainly still relevant, as underlining had for a while changed somewhat in semantics.

I say Markdown’s error was doing anything with underscores at all, especially given the programming context and the prevalence of underscores in snake_case and SCREAMING_SNAKE_CASE (Python being most heavily affected with its __magic__ methods, so that all implementations will be affected, rather than only some that have gone a certain way on word boundary matching), and it should have just been *italics* and **bold**.

Semantically, view italics as emphasis and bold as strong emphasis (basically where HTML 4 headed with and ), and the doubling of the asterisk makes perfect sense. The asterisks are an intensity modifier.

Re: We should have Markdown-rendered websites

#299
Actually, there's an app that does that : Joplin from https://github.com/laurent22/joplin

you can publicise the markdown text that you're writing in markdown. here's an example with my joplin server and with the desktop app running on linux. I get this link : https://joplin.mehdiguiraud.info/shares/8YBjIJwoNh15uVY900xq...

Re: We should have Markdown-rendered websites

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

Technically XML has some machinery to support more lightweight notations. It won't parse these notations, of course, but the information is accessible to the users of XML reader. The mechanism should work like that:

    
    
      
      
      
      
      ]>
    
      
        restructured text goes here
      
      
        markdown goes here
      
    
Post reply on HN