No we shouldn't. Markdown is just a small representation of markup that gets transformed to HTML.
We should have Markdown-rendered websites
301–310 of 351 posts
Re: We should have Markdown-rendered websites
#302No, why should we do that? Markdown websites just to render it BACK into HTML? That's not the browser's job.
The issue is, Markdown is nice because of its simplicity. The minute you start making it standard and widespread... feature-creep will happen and MD will just have as much noise as HTML does now.
Re: We should have Markdown-rendered websites
#303This 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-based web is actually easy to try. There is a number of browser extensions that render Markdown nicely. Install one, and get your friends do the same. Make your web server serve markdown files with a Content-Type: text/markdown or even text/plain header. Put some Markdown files there. Enjoy. It should just work.
I'd be curious about a browser that just does markdown
Re: We should have Markdown-rendered websites
#304Earlier quoted context omitted.
There are, but the markup is too simple and too "pure" to be useful in any meaningful way.
That's just an opinion. The reason nobody (relatively speaking) uses Markdown to author web pages is also that it's too simple to be useful.
I have 8000 pages that say it isn't: https://taoofmac.com/static/graph
Re: We should have Markdown-rendered websites
#305Re: We should have Markdown-rendered websites
#306Earlier 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.
The org-mode version is better in my opinion. Either [[link]] or [[link][text]].
Only uses square brackets and the optional text comes second which makes logical sense.
Re: We should have Markdown-rendered websites
#307I don't think markdown is simple for those don't know any tech.
Those who can write markdown can set up Hugo, Jekyll, Hexo well.
Re: We should have Markdown-rendered websites
#308I see some people in multiple comments discussing the need for some sort of standard for markdown if it were to be used for (goals...). Does nobody else remember the debacle and (limited) fight between Jeff Atwood and John Gruber (markdown's creator) over this? It was a big deal here, and of course, over at Coding Horror, Atwood's blog. And the reason was: Atwood was calling for some kind of standard, and Gruber acti…
I'll just ignore Gruber... his sloppyness in defining the details created a myriad of dialects of markdown
I agree with you! My point is that Gruber claims the sloppiness is intentional and actively resists fixing it. And if he -- the creator -- is not on board with standardizing markdown, maybe the whole endeavor is a dead end?
I mean, it could be done even against his wishes, but the project would already be starting with a big negative.
Re: We should have Markdown-rendered websites
#309Markdown 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…
> it just really feels like there shouldn't be that many additional features. A couple more of emphasis options, a couple less ways to do the same thing
There was a language like that once, it was called HTML. It had very basic set of features initially, but then someone needed text to blink, someone needed to display videos, someone needed to send forms, someone needed to use it to play games and here we are today, and it's not done yet. If it was implemented today, you will get exactly same result in near future, because everyone's "small set of features" together adds to infinity.
Re: We should have Markdown-rendered websites
#310FWIW, just a couple of weeks ago we started doing that for a new sqlite subproject: https://sqlite.org/wasm With the exception of one page, all of them are markdown, rendered on demand by the Fossil SCM. The one exception is an HTML file, which we need in order to host a small JS application.
When you say rendered on demand, you mean by the client, as in a page request? Why not just rerender to HTML on developer change? Genuinely curious why rendering on demand is preferred in this case.
> ... as in a page request?
Yup.
> Why not just rerender to HTML on developer change?
Because that's not how the Fossil SCM renders content. It has a cache, but only for certain high-CPU data like generation of zip files of the source tree. Caching markdown docs wouldn't work in all cases, anyway: when you link to a ticket, for example, it gets rendered differently depending on whether it's opened or closed. Thus the renderer has to know the current status of any fossil-internal constructs a doc links to. Of course, we could say "just update the cache of all docs which link to a ticket every time the ticket is updated," but That Way Lies Madness. In an Enterprise-level system that would possibly be worth doing. For the Fossil SCM it's overkill.
Though re-rendering on every page hit _sounds_ bad, we've been doing it in the Fossil SCM since it went into being and it has never caused us any undue performance issues. Every doc you see on https://fossil-scm.org/home>, as opposed to the non-doc URIs, is served directly from the SCM db and all (or very close to all) of it is either markdown or Fossil's older/original wiki format, both rendered on demand. CPU load is minimal and rendering is "fast enough" for everything we've ever done with it.