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.
We should have Markdown-rendered websites
291–300 of 351 posts
Re: We should have Markdown-rendered websites
#292Re: We should have Markdown-rendered websites
#293This 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?
From 2004
Re: We should have Markdown-rendered websites
#294Earlier 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
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
#295Markdown 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…
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
#296The 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
#297If 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?
Re: We should have Markdown-rendered websites
#298Markdown 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.
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
#299you 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
#300Markdown 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…
]>
restructured text goes here
markdown goes here