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. Why use markdown at all? Just use html.
"But html isn't style-agnostic" yes it is. CSS isn't style-agnostic. Instead of a markdown browser, how about a browser with a fixed stylesheet and no js? You don't even need a browser for that, that could just be a userscript that gets plugged into an existing browser. It'd break non-compliant websites that require javascript or custom css, but so would a markdown browser. Most people wouldn't write content for it, but most people wouldn't write content for a markdown browser either.
"But html is cluttered" it doesn't have to be. This is a valid webpage:
<!doctype html>
<title>Page Title</title>
<h1>Page Title</h1>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Ut ac lorem ut massa euismod vestibulum.
<p>Nullam rutrum blandit eleifend. Aenean a varius diam.
Morbi sodales velit nunc, vel vestibulum lorem tempus sodales.
Personally, I prefer writing in markdown, but that's no reason to insert a markdown renderer into browsers. HTML can already be as sleek and readable as you want. If we added a new type of markup for anybody with a personal preference, we'd never stop.
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 - the help files in an application really shouldn't need to invoke a web browser to view them when a lightweight markdown viewer would do the job. Not that there is a lightweight markdown viewer, mind you!
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 <p> element is replaced by <em>, and moreover define that an asterisk appearing within <em> content is replaced by </em>, 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.
Markdown is undoubtedly more readable, but HTML can be more readable than most people make it. And considering that the ultimate goal is to wind up with a layed-out, styled document, its capabilities in that regard are just plain-old more important, especially since markdown isn't going to replace WYSIWYG editors any time soon, and almost everybody who needs to know HTML can learn it relatively easily. Browsers collapse white space by default, so you've got a lot of flexibility with its formatting:
<!doctype html>
<title>
Page Title
</title>
<h1>
Page Title
</h1>
<p>
Lorem ipsum dolor sit amet, consectetur
adipiscing elit. Ut ac lorem ut massa
euismod vestibulum.
<p>
Nullam rutrum blandit eleifend. Aenean a
varius diam. Morbi sodales velit nunc, vel
vestibulum lorem tempus sodales.
--or--
<!doctype html>
<title> Page Title </title>
<h1> Page Title </h1>
<p> Lorem ipsum dolor sit amet, consectetur
adipiscing elit. Ut ac lorem ut massa
euismod vestibulum.
<p> Nullam rutrum blandit eleifend. Aenean a
varius diam. Morbi sodales velit nunc, vel
vestibulum lorem tempus sodales.
I get why many developers like this idea... Web developers are responsible for implementing the complex user-facing parts, and their primary weapon is text: doing extra work sucks, and when you're a hammer, everything looks like a nail. But developers are not designers, and design not being left to developers in mature organizations is no accident. Absolute, deliberate, limiting simplicity is always an attractive argument if you dismiss the value of, or maybe don't even understand the reason for the complexity. I won't deny the advantages of reader-view-level simplicity in web design: it's easier to visually parse, more performant, and easier to navigate compared to most web pages, similar to how books compare to magazines-- but about 225 million people per year in the US read magazines and I assure you most of them would not choose to have textural printouts in lieu of their current form. While people like having the option of a uniform, grey, easily visually parseable mode to view webpages, that's probably not what they want even most of the time, let alone as a deliberate limitation.
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:
<?xml version="1.0"?>
<!DOCTYPE myDoc [
<!NOTATION markdown PUBLIC "https://authority.org/markdown/v1.23">
<!NOTATION rest PUBLIC "urn:restructured-text/v4.56">
<!ELEMENT myDoc (note+)>
<!ELEMENT note CDATA>
<!ATTLIST note
notation NOTATION (markdown|rest) #REQUIRED>
]>
<myDoc>
<note notation="rest">
restructured text goes here
</note>
<note notation="markdown">
markdown goes here
</note>
</myDoc>
It's very similar yet much fuller-featured than commonmark, with support for definition lists, footnotes, tables, several new kinds of inline formatting (insert, delete, highlight, superscript, subscript), math, smart punctuation, attributes that can be applied to any element, and generic containers for block-level, inline-level, and raw content. In addition, it resolves ambiguities in the commonmark spec and parses in linear time with no backtracking.
Exactly what I was thinking, by omitting the <html> <head> and <body> HTML can be quite concise [1]. Additionally the closing </li> can be omitted from lists and <li> 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 <a href="..."> and closing with </a> is wayyy too boilerplate much for for something that is simply surrounded with [square](brackets) in markdown.
I have the opposite problem. HTML <a href> links are consistent with the rest of the language. <a href>Something</a> makes the same kind of sense as <em>something</em>.
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.
It's said that the father of LISP, John McCarthy, lamented the W3C's choice of SGML as the basis for HTML : « An environment where the markup, styling and scripting is all s-expression based would be nice. » The {lambda way} project could be an answer, small and simple: http://lambdaway.free.fr/lambdawalks/
In lambdatalk such a HTML code
<h1>Page Title</h1>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Ut ac lorem ut massa euismod vestibulum.
<p>Nullam rutrum blandit eleifend. Aenean a varius diam.
Morbi sodales velit nunc, vel vestibulum lorem tempus sodales.
is written like this
_h1 Page Title
_p Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut ac lorem ut massa euismod vestibulum.
_p Nullam rutrum blandit eleifend. Aenean a varius diam. Morbi sodales velit nunc, vel vestibulum lorem tempus sodales.
And you can also compute 3x4 writing {x 3 4} or compute the factorial of 100, compute a Fast Fourier Transform, draw complex graphics, ... it's a true programming language with a coherent syntax, unlike Markdown.
<ul>
<li> Item one
<li> Item two
<li> Item three
<li> Item four
</ul>
It has advantages over markdown lists, too: You never need to mess with semantic indentation to add additional paragraphs to a given line, and you don't have to manually number ordered lists the way some markdown flavours ask you to.
On the contrary - Markdown is essentially a superset of HTML, so unless you're using a renderer that strips it from the input, you can have the best of both worlds.
This property was super useful for a lightweight CMS I threw together a few years and which is still used by the original customer today. 99% of what they need to render is easily authored in Markdown, and this further helps ensure a commonality of style and device portability.
The original markdown parser supported html because it was basically just a preprocessor that added some syntactic sugar to html. The proposal here isn't just "what if browsers had a markdown preprocessor" (although I also think that would be questionable), but "what if browsers limited content down to only markdown, so that the web was all just clean, style-agnostic documents," and that clearly requires that markdown not support arbitrary html.
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 think that there is just a tiny bit of syntax lacking to make it just fine. Some actually is implemented in software like Pandoc or RedCarpet, there are a couple of ways to make tables (some better than others), LaTeX can be employed for formulas, some implementations have checklists, strikethrough, etc. It's just poorly standartized — and the spirit of original proposal (and misleading name) is at fault here as well, since later attempts to invent a standard mean very little when there is a dozen of different common implementations and not a single one is reasonably complete.
By the way, the fact that HTML was supposed to serve as an addition to Markdown doesn't help: you just cannot allow people to submit arbitrary HTML everywhere where something like Markdown is needed. To use it in comments on a forum you need to fully parse it anyway, explicitly enabling or disabling different features of some ubiquitous "full implementation".
Obviously, you cannot make an atrocity like a modern landing page in Markdown+. But… ok, I shouldn't be judgemental and claim such atrocities shouldn't exist — they can, but most blogs, forums (such as this one), etc. — really could have been just "viewer programs" of some standardized format, much more restrictive than HTML+CSS+JS, but a little less limited than Markdown.
All of this isn't very much related to the original topic, but seriously, I dream of some better version of Markdown someday becoming a de-facto standard markup language for all forums, messengers, blogging engines, whatever the general name for Jira is… You know what I mean.
I don't really have a solution, 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 (I mean, it's stupid to convert all of */-/+ to the same <li> elements), colors, better image embeddings (with captions), sidenotes, better ways to handle formulas (there are enough dedicated literals in Unicode to construct most simple formulas without the need for LaTeX, but they still need to be parsed to be rendered pretty) and simple UML-like stuff… I'm pretty sure the comprehensive list of features for 6-σ usecases cannot be THAT huge. Big, yes. Not endless. And most features surely have some "plain-text" (or very light special syntax) representations.
I realize that it was pretty much the intention behind HTML + CSS. But HTML + CSS stopped being that a very, very long time ago. 30 years have passed. By now, we should have a little better sense of what's needed to write & render most texts.
> 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.
> 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.
We broke a weird little markup language into something it was never meant to be because the last tower of crap got too high and collapsed on itself.
Now a webpage is html+css+javascript+a dozen frameworks. People are sick of it and want something better. Well HTML2 is better. Just HTML2, nothing else.
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 everything else it takes to develop, publish, and maintain a site. And it resolves the markdown flavors issue.
The thing is, people could choose to publish, simple uncomplicated sites now -- it would be cheap and easy, too. The HTML is barely more complicated than the equivalent markdown, and it would take a few lines of CSS to apply a basic style.
The many sites that choose to be complicated, cluttered, and expensive will continue to be so, for the same reasons they are now. Markdown would just be another way to build simple sites, which they don't want.
For people considering adding Markdown support to web browsers or other publishing tools, please consider adopting Djot instead: https://github.com/jgm/djot
It's very similar to the Markdown syntax we all know and love/hate, but fixes many inconsistencies in the spec, and also makes it possible to parse a document in linear time, with no backtracking. It is also much fuller-featured than commonmark, with support for definition lists, footnotes, tables, several new kinds of inline formatting (insert, delete, highlight, superscript, subscript), math, smart punctuation, attributes that can be applied to any element, and generic containers for block-level, inline-level, and raw content.
I get this, but OTOH it is IMO best to distribute digital artifacts in the format that is most useful for editing or creating derivative works. This is the free software philosophy but also a societal good. Many of us learned HTML and web technologies by reading the source code of websites, and we've closed that door behind us with all of the build steps that turn our actual code into a computer-readable-only mess which we send out for consumption by normal users' browsers. It would be nice if "view source" showed you something like what the author actually wrote in their text editor.
you can distribute websites as markdown! Return markdown with a plain text content type and it'll show as markdown, which was designed to look good as-is and not require rendering to HTML
This is actually horrible for society as it implies that the Web Browser will have to implement a billion different parsers for all of the separate file formats it supports, which not only causes it to have a ridiculously large attack surface but pretty much implies there will only be a couple serious separate implementations (if even that soon...) as it is just too difficult for even a large company now to build a browser.
Meanwhile, it doesn't even ensure the property of being able to view source, as people can and do obfuscate things they don't want you to see, and if people want you to see the source code there is nothing preventing them from making that entirely pipeline visible, including, but certainly not limited to, shipping a trivial markdown parser to the browser instead of doing the conversion on a server.
In a perfect world, the browser should have simply provided something like canvas hooked up to something like WebAssembly, and we should have provided for everyone a trivial markup file format rendered that people could include by default and a handful of graphic file format implementations that could be easily mix-and-matched to pull just the ones people wanted into their site.
>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.
I came to write something similar to this, basically.
If anything we should push for websites to divide content from presentation: if html tags were used properly there would be no need for markdown.
And on that matter, pushing for proper use of html tags in documents is a more achievable goal than asking everybody to just drop html and write markdown.
The difference is 30 years of websites and tools being built on HTML. There's an opportunity cost to consider: is formatting simple websites in Markdown and rendering them natively that much more valuable than simply writing them in HTML or using a Markdown-to-HTML tool that it's worth the cost of creating standards, implementing them in browsers, etc. as opposed to putting those efforts elsewhere?
If you were starting from scratch, maybe. But it seems like we've already reached a point where existing solutions for Markdown-to-HTML get you almost all of the value and none of the cost.
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).
>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).
HTML is already a markup language. You could just as easily make basic websites using HTML and some basic inline CSS.
(They’d even have some extra features missing from Markdown that I’d consider still part of a basic content formatting suite like floating or multi-column layouts. They’d even have a defined standard for machine readable metadata!)
The problem is that people don’t make websites like that very often, even though they can. This is trying to solve a problem that doesn’t currently exist.
What Markdown provides here is an even lower barrier to entry for the majority of people... they just write text, learn a fraction more Markdown to so more... and if they want total control they eventually learn HTML too.
It's not mutually exclusive... Markdown includes HTML.
Markup is not the barrier to entry. Nobody in 2022 is building HTML-only websites. Even 20 years ago CMSes let hundreds of thousands of people write blogs online.
Let's say somebody takes the time to learn Markdown. Then what?
Are they going to then also learn how to select a web host, how to set up SSL, how to use CSS to make the website look the way they want?
They won't. That's why Wordpress, and later Facebook, won the online publishing wars.
—I’d say it’s the other way around isn’t it? Wouldn’t Markdown be a subset of HTML, since all markdown can be expressed in HTML but not all HTML can be expressed in Markdown?—
Edit: Markdown can contain HTML that gets meaningfully interpreted as markup as well.
I’d also say HTML is not difficult to write, even for someone new to the concept. I don’t think anyone making their GeoCities homepage was too strained learning HTML, and those were leagues more advanced than what’s possible with only Markdown!
If you want people to be excited about self-publishing online again, it’s probably best to start with the markup language that allows for some fun :)
Yes, so all websites are already written in markdown. Its just tjat No browsers support the typical header/list shorthands, but that doesn’t matter because even if they did you’d still need more tages to get interactivity and styling working.
People aren’t imagining a world where markdown makes anything simpler they are imagino by that a format change would make people build less complex websites. But why would they? It’s not HTML that makes the Twitter front end or Facebook complicated, it’s the desisted functionality, which wouldn’t change even if the spice code looked more like markdown and less like html.
So are Markdown rendering libraries entirely pointless? I'm not sure where you'd get the impression that HTML is a subset of HTML rather than Markdown being a superset of HTML. (even that is very reductive, though)
This misses the real point of Markdown, which isn't to be simple or opinionated but to be readable by the end user in both forms (raw or rendered).
In case of a web site there is never the expectation of the source being easy to read for the end user. If you want to create a simple page – great, go for it. The only minor change will be replacing markdown tags with HTML ones. And there's plenty of tooling which does that trivially.
Deliver as markdown, but with a single line header:
<!DOCTYPE html><title>Foo</title><script src=mydelayedmarkdownparser.js></script><PLAINTEXT>
[[insert your markdown here]]
A document delivered as pure markdown, that will get spidered by any search engine that renders JavaScript (or that reads the document as text), and you don’t need to ask anyone to change anything. HTML has no closing </plaintext> end tag, so markdown can be free-form and securely include any unescaped <>”’ characters (raw HTML code) you need into your markdown and the browser will treat it as pure text (unlike the <XMP> tag which can be ended with </XMP> - even weirder lexing).
The key is that although the <plaintext> tag is deprecated, every browser has to support it (partially because removing support for <plaintext> would cause security issues for existing pages!) The <plaintext> tag is really very special, quite different from any other tag, and it radically interrupts HTML document lexing/parsing.
What is needing then, is adding the "type" attribute in <plaintext> command, that browsers with their own implementation can optionally use it instead in order to render with the user's settings if desired.
However, that still forces you to serve HTML, so it is not good. My idea is adding a "Interpreter" response header, which indicates which files can be used to render files (documents, audio, video, pictures, etc) that the client implementation does not understand already. The end user can also specify their own overrides, if desired.
Fun related fact people may not be aware of: you can do basically this with arbitrary XML files, defining a stylesheet which transforms the XML into HTML however you like using XSLT. As an example, Atom feeds on my website (such as <https://chrismorgan.info/blog/tags/meta/feed.xml>) render just fine in all mainstream browsers, thanks to this processing instruction at the start of the file:
(Mind you, XML is hard to work with in browsers, because it’s been only minimally maintained for the last twenty or so years. Error handling is atrocious (e.g. largely not giving you any stack trace or equivalent, or emitting errors only to stdout), documentation is lousy, some features you’d have expected from what the specs say are simply unsupported, and there are behavioural bugs all over the place, e.g. in Firefox loading any of my feeds that also fetch resources from other origins will occasionally just hang, and you’ll have to reload the page to get it to render; and if you reload the page, you’ll have to close and reopen the dev tools for them to continue working.)
I mean it _sounds_ good, but how will we cram a million ads down user's throats and measure every twitch of their input devices? It's almost as though the author is suggesting that web site proprietors might be more interested in "serving content" than "driving engagement" which I find disturbing and upsetting.
But the engaged clickable web is anyways dead. This post is a static HTML file hosted on IPFS with no back links to my carefully curated blog and media presence. No branding. It's because I've accepted that people's bullshit-radar is sensitive towards overly optimized engagement content. Rather I want my text to be read and those that care will anyways online-search me. It's not my idea btw. The web has reached peak clickability: https://tedgioia.substack.com/p/has-the-internet-reached-pea...
I think covid is when the internet jumped the shark for Joe Average.
You would get banned from twitter, facebook, reddit, instagram etc for saying what was official policy until _yesterday_. The sheer insanity of that policy left the terminally online in charge everywhere and the quality of every website suffered. If I look back to reddit posts which google still brings up more than half the people are banned. These are people who wrote thousand word replies to technical problems and were pillars of the community. The only ones left are the mentally ill unemployed since they are the only ones who have time to keep track of what is allowed there.
HN was headed down the same hole until that hilarious post by PG about heretics that got flagged for 8 hours. I imagine at that point it hit everyone in charge here that the people making the most noise were not their friends.
People are "big-picture" missing why this is an important idea. I had a prof put it like this once: The great tragedy of the web is the following:
HTML made the web easy to read.
But you know what made the web easy to write? Facebook. Facebook was undeniably the technology that made it so that roughly everybody could write things on the web to be read by everyone.
I really like the direction of this, because it points toward the possibility of a "web that is easy to write."
This is nonsense. There were tons of things that made the web easy to write before FB. That is not what made FB successful. It was a combination of a lot of little features plus the big innovation that your profile had to be your real life identity early on. That was the thing prior social networks didn't do. It enabled the uniquely Facebook experience of being able to find past friends and more distant family.
> the big innovation that your profile had to be your real life identity early on.
This came after facebook was wildly successful, so not early on. I also have never met a single person who was attracted by it, or was confused as to who their friends were before it existed. That being said, tying real names to online identity allowed facebook to buy data from brokers to fill out the sliced up audiences they sell to advertisers, so maybe it was important to their profitability.
What made FB successful was that it was a platform that other developers could program for, so it filled up with games and quizzes. Farmville,
"Which Harry Potter Friends Spice Girl Are You?" etc. was all the edge that it took to kill myspace, a site which seemed to stop any sort of development about 10 minutes after launch.
But, as you say, even myspace made it very easy to write on the web. You could scribble on other people's "walls", put whatever you wanted on your own page, and every profile came with a blog.
Against what you say, however, is the timeline where you could just post random crap and all of your friends would see it and comment on it; the dopamine stream. There's no easier way to write than to spit out a random sentence or upload a random picture, and broadcast that instantly to hundreds of people.
LOL. Apparently I am old, but I remember the web before Facebook (or Google or…) existed. Everybody could (and many did) write on the web before Facebook. Geocities, My Space, or just create your own website. Believe it or not, but it was far simpler and cheaper to create your own website back then. There were tons of free hosting sites back then. You know what killed all of that? Facebook. This is why I am excited by the notion of Facebook dying. Maybe we can get back some of what we lost.
I remember my first website experiment, hosted on "20megsfree". 20 megabytes of free hosting on a subdomain, they'd put an ad banner at the top, and you could pay for more / to remove the banner.
..and oh wow the domain still exists. Homepage is unchanged from 2001. Copyright line in the footer stopped updating in 2005 though so no idea if it would still work...
You already can render markdown. It shows as what it is: text.
If you want to render markdown as something else, you need to define what that other thing is. If you're suggesting we render it as a webpage, well webpages are made of HTML and CSS--so you're saying you want to render markdown as HTML/CSS.
We can already do that. There are a plethora of tools available to do that.
Readit News
"But html isn't style-agnostic" yes it is. CSS isn't style-agnostic. Instead of a markdown browser, how about a browser with a fixed stylesheet and no js? You don't even need a browser for that, that could just be a userscript that gets plugged into an existing browser. It'd break non-compliant websites that require javascript or custom css, but so would a markdown browser. Most people wouldn't write content for it, but most people wouldn't write content for a markdown browser either.
"But html is cluttered" it doesn't have to be. This is a valid webpage:
Personally, I prefer writing in markdown, but that's no reason to insert a markdown renderer into browsers. HTML can already be as sleek and readable as you want. If we added a new type of markup for anybody with a personal preference, we'd never stop.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 - the help files in an application really shouldn't need to invoke a web browser to view them when a lightweight markdown viewer would do the job. Not that there is a lightweight markdown viewer, mind you!
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.
IMO this issue should and can be easily solved by editor/viewer by rendering tags with lower contrast.
Deleted Comment
It's very similar yet much fuller-featured than commonmark, with support for definition lists, footnotes, tables, several new kinds of inline formatting (insert, delete, highlight, superscript, subscript), math, smart punctuation, attributes that can be applied to any element, and generic containers for block-level, inline-level, and raw content. In addition, it resolves ambiguities in the commonmark spec and parses in linear time with no backtracking.
Further discussion lower in this thread: https://news.ycombinator.com/item?id=33553293
Quickstart for Markdown users: https://github.com/jgm/djot/blob/main/doc/quickstart-for-mar...
Some more in-depth examples, showing how Djot would be rendered into HTML: https://htmlpreview.github.io/?https://github.com/jgm/djot/b...
The worst part about HTML is the links, though. Anchor tags are awful. Having to repeatedly type <a href="..."> and closing with </a> is wayyy too boilerplate much for for something that is simply surrounded with [square](brackets) in markdown.
[1] I go to https://meiert.com/en/blog/optional-html/ for reference.
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.
In lambdatalk such a HTML code
is written like this And you can also compute 3x4 writing {x 3 4} or compute the factorial of 100, compute a Fast Fourier Transform, draw complex graphics, ... it's a true programming language with a coherent syntax, unlike Markdown.The difference in legibility is pronounced.
Especially if you don't want weird whitespace things.
Nobody complains that the assembly code that runs their application is cluttered and illegible.
On the contrary - Markdown is essentially a superset of HTML, so unless you're using a renderer that strips it from the input, you can have the best of both worlds.
This property was super useful for a lightweight CMS I threw together a few years and which is still used by the original customer today. 99% of what they need to render is easily authored in Markdown, and this further helps ensure a commonality of style and device portability.
Markdown is deeply limited, that's true, but I often think that there is just a tiny bit of syntax lacking to make it just fine. Some actually is implemented in software like Pandoc or RedCarpet, there are a couple of ways to make tables (some better than others), LaTeX can be employed for formulas, some implementations have checklists, strikethrough, etc. It's just poorly standartized — and the spirit of original proposal (and misleading name) is at fault here as well, since later attempts to invent a standard mean very little when there is a dozen of different common implementations and not a single one is reasonably complete.
By the way, the fact that HTML was supposed to serve as an addition to Markdown doesn't help: you just cannot allow people to submit arbitrary HTML everywhere where something like Markdown is needed. To use it in comments on a forum you need to fully parse it anyway, explicitly enabling or disabling different features of some ubiquitous "full implementation".
Obviously, you cannot make an atrocity like a modern landing page in Markdown+. But… ok, I shouldn't be judgemental and claim such atrocities shouldn't exist — they can, but most blogs, forums (such as this one), etc. — really could have been just "viewer programs" of some standardized format, much more restrictive than HTML+CSS+JS, but a little less limited than Markdown.
All of this isn't very much related to the original topic, but seriously, I dream of some better version of Markdown someday becoming a de-facto standard markup language for all forums, messengers, blogging engines, whatever the general name for Jira is… You know what I mean.
I don't really have a solution, 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 (I mean, it's stupid to convert all of */-/+ to the same <li> elements), colors, better image embeddings (with captions), sidenotes, better ways to handle formulas (there are enough dedicated literals in Unicode to construct most simple formulas without the need for LaTeX, but they still need to be parsed to be rendered pretty) and simple UML-like stuff… I'm pretty sure the comprehensive list of features for 6-σ usecases cannot be THAT huge. Big, yes. Not endless. And most features surely have some "plain-text" (or very light special syntax) representations.
I realize that it was pretty much the intention behind HTML + CSS. But HTML + CSS stopped being that a very, very long time ago. 30 years have passed. By now, we should have a little better sense of what's needed to write & render most texts.
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.
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.
We broke a weird little markup language into something it was never meant to be because the last tower of crap got too high and collapsed on itself.
Now a webpage is html+css+javascript+a dozen frameworks. People are sick of it and want something better. Well HTML2 is better. Just HTML2, nothing else.
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 everything else it takes to develop, publish, and maintain a site. And it resolves the markdown flavors issue.
The thing is, people could choose to publish, simple uncomplicated sites now -- it would be cheap and easy, too. The HTML is barely more complicated than the equivalent markdown, and it would take a few lines of CSS to apply a basic style.
The many sites that choose to be complicated, cluttered, and expensive will continue to be so, for the same reasons they are now. Markdown would just be another way to build simple sites, which they don't want.
It's very similar to the Markdown syntax we all know and love/hate, but fixes many inconsistencies in the spec, and also makes it possible to parse a document in linear time, with no backtracking. It is also much fuller-featured than commonmark, with support for definition lists, footnotes, tables, several new kinds of inline formatting (insert, delete, highlight, superscript, subscript), math, smart punctuation, attributes that can be applied to any element, and generic containers for block-level, inline-level, and raw content.
Some examples, showing how Djot would be rendered into HTML: https://htmlpreview.github.io/?https://github.com/jgm/djot/b...
Standardization of the spec is good. Requiring quirky behavior and blank lines that hurt reading is bad.
HTML is an extensible language. Markdown is not.
Meanwhile, it doesn't even ensure the property of being able to view source, as people can and do obfuscate things they don't want you to see, and if people want you to see the source code there is nothing preventing them from making that entirely pipeline visible, including, but certainly not limited to, shipping a trivial markdown parser to the browser instead of doing the conversion on a server.
In a perfect world, the browser should have simply provided something like canvas hooked up to something like WebAssembly, and we should have provided for everyone a trivial markup file format rendered that people could include by default and a handful of graphic file format implementations that could be easily mix-and-matched to pull just the ones people wanted into their site.
[1] https://gemini.circumlunar.space/docs/faq.gmi
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.
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.
If anything we should push for websites to divide content from presentation: if html tags were used properly there would be no need for markdown.
And on that matter, pushing for proper use of html tags in documents is a more achievable goal than asking everybody to just drop html and write markdown.
If you were starting from scratch, maybe. But it seems like we've already reached a point where existing solutions for Markdown-to-HTML get you almost all of the value and none of the cost.
For browsers to also support markdown, there should be some use case that isn’t already well-supported.
HTML has had the exact same problems.
You can say "CommonMark spec" and it's solved, isn't it?
Standard is not only specification, but also tacit agreement by many parties to use same standard.
People that have skin in the game usually want a say on what flavour should it be.
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).
Yes please. Perfect: to want something that can be done; to need something that can happen.
Is it though?
From 2004
https://daringfireball.net/projects/markdown/
(They’d even have some extra features missing from Markdown that I’d consider still part of a basic content formatting suite like floating or multi-column layouts. They’d even have a defined standard for machine readable metadata!)
The problem is that people don’t make websites like that very often, even though they can. This is trying to solve a problem that doesn’t currently exist.
Dead Comment
You can include in Markdown any and all HTML.
What Markdown provides here is an even lower barrier to entry for the majority of people... they just write text, learn a fraction more Markdown to so more... and if they want total control they eventually learn HTML too.
It's not mutually exclusive... Markdown includes HTML.
Let's say somebody takes the time to learn Markdown. Then what?
Are they going to then also learn how to select a web host, how to set up SSL, how to use CSS to make the website look the way they want?
They won't. That's why Wordpress, and later Facebook, won the online publishing wars.
Edit: Markdown can contain HTML that gets meaningfully interpreted as markup as well.
I’d also say HTML is not difficult to write, even for someone new to the concept. I don’t think anyone making their GeoCities homepage was too strained learning HTML, and those were leagues more advanced than what’s possible with only Markdown!
If you want people to be excited about self-publishing online again, it’s probably best to start with the markup language that allows for some fun :)
Yes, so all websites are already written in markdown. Its just tjat No browsers support the typical header/list shorthands, but that doesn’t matter because even if they did you’d still need more tages to get interactivity and styling working.
People aren’t imagining a world where markdown makes anything simpler they are imagino by that a format change would make people build less complex websites. But why would they? It’s not HTML that makes the Twitter front end or Facebook complicated, it’s the desisted functionality, which wouldn’t change even if the spice code looked more like markdown and less like html.
In case of a web site there is never the expectation of the source being easy to read for the end user. If you want to create a simple page – great, go for it. The only minor change will be replacing markdown tags with HTML ones. And there's plenty of tooling which does that trivially.
But the source is easier to read for you (the author), directly in your code editor or even simply edit the file live on the server via FTP or SSH.
The key is that although the <plaintext> tag is deprecated, every browser has to support it (partially because removing support for <plaintext> would cause security issues for existing pages!) The <plaintext> tag is really very special, quite different from any other tag, and it radically interrupts HTML document lexing/parsing.
Use something like https://whatismarkdown.com/how-to-have-markdown-in-realtime-... to read the content of the <plaintext> and dynamically render your markdown into HTML.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/pl...
Edit: and of course there is the HTTP header Content-Type: text/markdown which could be used by browsers to render a markdown document - see “The text/markdown Media Type” RFC https://www.rfc-editor.org/rfc/rfc7763.html and https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
However, that still forces you to serve HTML, so it is not good. My idea is adding a "Interpreter" response header, which indicates which files can be used to render files (documents, audio, video, pictures, etc) that the client implementation does not understand already. The end user can also specify their own overrides, if desired.
/s
But the engaged clickable web is anyways dead. This post is a static HTML file hosted on IPFS with no back links to my carefully curated blog and media presence. No branding. It's because I've accepted that people's bullshit-radar is sensitive towards overly optimized engagement content. Rather I want my text to be read and those that care will anyways online-search me. It's not my idea btw. The web has reached peak clickability: https://tedgioia.substack.com/p/has-the-internet-reached-pea...
The social media has gone absolutely toxic in an frantic attempt to maximize revenue per user.
You would get banned from twitter, facebook, reddit, instagram etc for saying what was official policy until _yesterday_. The sheer insanity of that policy left the terminally online in charge everywhere and the quality of every website suffered. If I look back to reddit posts which google still brings up more than half the people are banned. These are people who wrote thousand word replies to technical problems and were pillars of the community. The only ones left are the mentally ill unemployed since they are the only ones who have time to keep track of what is allowed there.
HN was headed down the same hole until that hilarious post by PG about heretics that got flagged for 8 hours. I imagine at that point it hit everyone in charge here that the people making the most noise were not their friends.
HTML made the web easy to read.
But you know what made the web easy to write? Facebook. Facebook was undeniably the technology that made it so that roughly everybody could write things on the web to be read by everyone.
I really like the direction of this, because it points toward the possibility of a "web that is easy to write."
This came after facebook was wildly successful, so not early on. I also have never met a single person who was attracted by it, or was confused as to who their friends were before it existed. That being said, tying real names to online identity allowed facebook to buy data from brokers to fill out the sliced up audiences they sell to advertisers, so maybe it was important to their profitability.
What made FB successful was that it was a platform that other developers could program for, so it filled up with games and quizzes. Farmville, "Which Harry Potter Friends Spice Girl Are You?" etc. was all the edge that it took to kill myspace, a site which seemed to stop any sort of development about 10 minutes after launch.
But, as you say, even myspace made it very easy to write on the web. You could scribble on other people's "walls", put whatever you wanted on your own page, and every profile came with a blog.
Against what you say, however, is the timeline where you could just post random crap and all of your friends would see it and comment on it; the dopamine stream. There's no easier way to write than to spit out a random sentence or upload a random picture, and broadcast that instantly to hundreds of people.
Facebook, and nothing else much comes close.
(Again, I say this as someone who mostly hates it)
This came afterwards. In the beginning it was just a showcase of life moments to share with others. Lots of fun and lots of cringe.
..and oh wow the domain still exists. Homepage is unchanged from 2001. Copyright line in the footer stopped updating in 2005 though so no idea if it would still work...
If you want to render markdown as something else, you need to define what that other thing is. If you're suggesting we render it as a webpage, well webpages are made of HTML and CSS--so you're saying you want to render markdown as HTML/CSS.
We can already do that. There are a plethora of tools available to do that.
Deleted Comment