So Markdown is this Lightweight Markup Language. Everyone (relative; among programmers, writers, and other “power-users”) uses it. LLMs use it. So it’s destined to eat the world. But it doesn’t mean Markdown is good.
↫ Artyom Bologov
We have these crazy fast and complex computers, but I’m still supposed to style text with obscure, arbitrary symbols, like an animal? We invented WYSIWYG decades ago, and our computers should be able to figure out how to properly share styled/unstyled text without us users having to learn markup languages using arcane symbols that require weird claw grips to type.
The widespread use of Markdown is not indicative of its merits; it merely underlines the utter failure of the computing industry to fix basic problems.
I am in love with what markdown plus pandoc have given me.
Mind you, I mostly use plain text based tool because of what I do (programming). I favor everything that I can read directly on my editor of choice. So for documents that do not need anything fancy, it is great. If I just need simple stuff, like paragraphs, several levels of titles and the odd table, I can write that in markdown focusing on content, not form, using the same tool I use for my other work: a text editor and integrating wonderfully with my workflow, where git and diffs happen as routine.
The documents can later be converted to a pdf or something else to please clients, and in that step I can put some extra time to improve the form of the already completed content. I also like the separation between the source document (the markdown) and the target document (usually a pdf).
I could be using latex or something like that, but markdown is enough most of the time and ir is very legible in its source form.
I’d even say that WYSIWYG has resulted in so many flaws. So many documents that may look fine but are internally flawed in its structure. Formatting via white space and newlines that break with different tools…
WYSIWYG has resulted in many being able to use the tools badly. They are good in the sense that they provide a nice learning curve, the problem is that many just don’t take the steps needed to do things properly (like using proper styles instead of ad hoc formatting).
IMO, for many use cases the text based tools are much supperior as they focus more on content and less in form. An for that tools like markdown (or rst) provide a very low barrier of entry option.
You somewhat summed it up why we never get a reliable working WYSIWYG editor. Because why the hassle as a dev when you anyway write code in syntax.
I very much disagree. The whole notion of using a tool like word, with it’s myriad ribbons and buttons, is now an anachronism. You ( or you and an AI or just the AI ) will create content. There maybe some light styling to indicate headings and lists and such in the content – as markdown offers – but otherwise there is very little need for any additional styling, especially because you have no notion of the medium used to consume the content.
The consumers AI will then reformat your content, and very likely edit it for them based on their preferred way of consuming that content. The consumer may not even read it at all but simply have the AI tell them about it or make a tiktok like video about it.
The future of content is you talking to an AI and it putting it together, and for the purists perhaps a totally distraction free typing experience where it’s just you and your thoughts on a blank page. It’s certainly not hundreds of buttons just in case you want an italicized underlined heading at 24pt and the user consuming that on an HTML page with ads everywhere. That world is dying, and good riddance .
I would love to have both for my documentation. Nice syntax behind a reliable WYSIWYG interface.
Word (processors) is (are) at least as arcane as markup language.
Listen, we already have plethora of Markdown editors that render everything without you even seeing underlying markdown (yet saving into MD). What’s the problem? I fail to see the problem, so there is no need for any solution.
Sometimes I just want to focus, run my computer without any graphical interface, and can work on some code or write and format some document without any visual distractions.
I agree that GUIs could be way better, but the arcane art of using a computer like an animal has its uses.
Markdown is my favorite thing invented in the recent past. I never want to go back to using shitty WYSIWYG editors or heavy markups.
Markdown is magical because it can be rendered, but looks great as plain text, which is how I mostly interact with it.
It is used for doc comments in modern programming languages and it easily beats HTML in this role, which was often a historic choice.
Thom Holwerda,
This almost sounds like an argument in favor of using AI to stylize text without users needing to manually format the text. IMHO this seems doable.
Osnews has decades worth of articles, have you ever wondered what would happen if you used that data to train an AI? Not trying to suggest there is a good commercial reason to do it, but I’m often intrigued by these kinds of ideas.
Edit: Hopefully asking these questions doesn’t come off as provocative, but wouldn’t you be curious to see what the AI can learn from your own works?
I don’t need a computer to regurgitate stale shit at me when I am perfectly capable of producing new shit myself.
Thom Holwerda,
Sure, I know your take on LLMs to generate content. However you expressed a frustration “our computers should be able to figure out how to properly share styled/unstyled text without us users having to learn markup languages”, which is a problem that AI might be able to solve by analyzing content you’ve previously created to help you apply styles to new content.
I understand the more widespread public rational against AI that’s trained on public data and/or takes away jobs, but is it fair to say that your philosophical opposition to AI extends beyond this, even if AI is using your own data to do your own job? The question that comes to my mind is this: who is this unfair against?
that’s actually good point.
Shit indeed.
“our computers should be able to figure out how to properly share styled/unstyled text without us users having to learn markup languages using arcane symbols that require weird claw grips to type.”
Sorry, we are way to busy dazzling you with shitty pseudo-AI that does not work as expected to bother making anything useful. -Software companies
This article shows a fundamental misunderstanding of *why* Markdown exists and was happily welcomed.
Non-technical writers welcomed a way to write and save text documents in a manner that 1) works with any tool that accepts plain text, and 2) does not lock you in to a tool. Markdown is not intended to replace LaTex, or HTML, or Word .DOCX. It is the equivalent of .RTF with the *important* benefit of being human-readable.
Why does this matter? Because sometimes you don’t have full control over every device you want to write on. Many of us have day jobs with locked-down desktops. We work across platforms/OS’s. We like using vintage computers alongside modern computers. We like writing in “distraction free” or simplified toolsets. Our needs are fairly simple, but yes, sometimes we really want to be able to indicate **bold** or *italicized* words (which seems to horrify the author of the above article.) So, without Markdown, what are our options?
– RTF fits the bill is many ways, and is helped by being an older format. This means you can use word processors dating back to the 1980s for many platforms (DOS, Mac, Amiga, etc). But — it excludes pure text editors (including sending documents in plain text emails. It is also NOT human-readable.
Every other non-human-readable format suffers the same problem, made worse by either proprietary lock-in or by the fact that older editors and word processors won’t be gaining support for new formats, ever.
– HTML would be preferred by the technical cognoscenti like the article’s author – but it is far harder to learn than Markdown, and far messier to read. The core Markdown syntax does not rely on “code” – it simply unifies a set of very readable plain text conventions for certain formatting, which can be easily parsed later – but don’t have to be parsed to be understood by a regular human.
– TXT is really the only file format that meets every need I listed above, for a portable writer who wants to work anywhere, any time, and never have their text locked in to an irretrievable machine-readable format. Of course, TXT misses the key formatting assists which Markdown provides.
Markdown is a very human response, providing a minimally complex solution to an intractable problem with writing on electronic devices. Like any good idea, it can be made unwieldy by fracturing and feature creep. But the need is real. That’s why, over the past five years, there has been continual pressure from **actual users** for developers to actively embrace Markdown in their tools. Even though the whole point of Markdown is that “we can do it ourself with plain text.”
TorontoDave,
True. It is a universal format that can be edited by any tool, and infinitely extensible. And given it is plain text any dialects do not need to be interchangeable. Because even without tools humans can understand it.
So, you put a diagram that requires DOT, or Mermaid? Even if your MD editor does not have the capability to “render” it to a visual chart, it is extremely easy to read the structure as a human.
Markdown is very useful as a technical note sharing tool, and it will be here to stay for a long while.
(Note: the “marks” like *for italics* or 1. 2. 3. for lists have been used by humans long before markdown was a thing. Its syntax is natural)
edit: (sample but still not TT tags here!)
sukru,
Side debate:
You can call it italic, but when I read/write *text* in the context of human text it means bold. For example if I read *ahhh* in a screen play I would be thinking *ahhh* and not *ahhh*. This probably doesn’t matter much for most text, but since it carries semantic meaning in the context of a markup language then people may have different feelings about what it should map to.
Also, I don’t consciously know why, but for as long as I can remember this is how I’d naturally write a list in text…
1)
2)
3)
Alfman,
I get what you mean. We have small differences in “natural” semantics. Here we would say 1,234.09 But in many places of Europe they would use 1.234,09 instead. Or they use 23/01 to say January 23rd instead of the *correct* form of 01/23 🙂
sukru
That’s the point. Not everyone agrees and “natural” becomes relative.
Regarding dates, even after an american education, MM/DD/YYYY comes across as illogical and wrong. At least DD/MM/YYYY is consistent However most people in computer science would prefer YYYY-MM-DD as the most logical in terms of digit significance consistency. and has been standardized for most SQL database. YYYY-MM-DD is the only arrangement of date digits that allows dates to sort naturally when represented as text and using dashes can be used in filename whereas slashes cannot. I do think this can be considered best, but not enough to override historical conventions.
Alfman, I think the core point still remains.
*this* is intuitive as a form of emphasis and you’re just arguing over which form of visual rendering represents weak or strong emphasis and whether **this** is needed to invoke the strong form.
…and given that the CommonMark spec specifically says that *this* maps to HTML EMphasis and **this** to HTML STRONG emphasis, which are semantic tags, not presentational ones, that browser default stylesheets are responsible for mapping to italic and bold, and that it’s intuitive that **this** is *this* but moreso, I think it’s a reasonable decision.
ssokolow (Hey, OSNews, U2F/WebAuthn is broken on Firefox!)
Bare in mind my post was in response to sukru’s point about what feels most natural. I understand a markup standard is free to do something different.
Maybe, but it does seem a bit silly to me that a markup standard should have both _text_ and *text* map to the same thing. That obviously wasn’t necessary nor consistent and IMHO it would have been sensible to map _text_ to italics/em and *text* to strong/bold. But it doesn’t matter, it’s all arbitrary anyway,
That’s fair. _em_ and *strong* does feel natural, and it wouldn’t surprise me if CommonMark would have done that if they were breaking from Markdown instead of unifying it.
Alfman,
I agree, that should be standard. 01/18 and 18/01 come from our ways of speech, though.
ssokolow,
I did not know about CommonMark. I just used whatever tool I had (github, vscode, …) to choose the dialect.
But this reminds me of the famous xkcd:
https://xkcd.com/927/
They are just increasing the number of standards by another one.
No, actually. CommonMark has been very successful at reducing the number of dialects in active use, and dialects like GitHub Flavoured Markdown are now explicitly being specified as compatible supersets of CommonMark… and it’d be one less if Reddit would update old.reddit.com to use the CommonMark parser that http://www.reddit.com applies to the same database records.
(Yes, the same posts render differently on old.reddit.com and http://www.reddit.com.)
Interesting,.. so they actually managed to keep people in line.
I’d say it’s that, once there was a proper spec, the forces that keep JSON implementations standard won out… especially when extensions like CommonMark-based GFM (which various CommonMark parsers just let you toggle on) served to address the needs which produced things like HOCON, JSONC, and JSON5.
Until CommonMark, Markdown had no proper spec.
I don’t see RTF as something you can compare to MD or TXT. It’s more like ODT, DOC, DOCX … The fact that you can’t read it without special software (unlike simple less / cat, etc) means it’s NOT portable in any way.
RTF grew out of an era where things like WordStar had normalized using non-printable single-byte control codes to denote rich formatting. (eg. 0x02 for toggling boldface)
In that sense, RTF’s LaTeX-esque syntax was unusually human-friendly.
I hate markdown (and relatives) implicit usage with a passion: the main online git tools (github/gitlab) automatically format using markdown. I format plain text when writing pull request descriptions, markdown makes this hard.
I can no longer only think about the content, but also how the tool will interpret it, making me constantly switch between preview and the text itself. And don’t EVER interpret git commit message formatting.
Plain text is WYSIWYG.
you just didn’t embrace MD, so it became an obstacle for you using pure text, which has lots of limitations markdown doesn’t have. It’s a “you” problem IMO.
Did you notice the “implicit usage” part? I like markdown itself, I hate it transforming text that was never intended for markdown.
The easiest example I can give is gitlab/github taking the first commit message in a MR, using that as a description, and interpreting it as markdown.
OK, that is just broken. GitLab doesn’t control commit messages, so it shouldn’t be blindly interpreting them as Markdown… doesn’t surprise me though.
Compared to GitHub, they’ve got a lot of subtle irrtations in their UX that tend to have a “they just didn’t think through the implications/edge cases” vibe to them.
asciidoc and rst are both objectively better. I hate that markdown has so much inertia.
yes, but also not as standardized, with multiple variations making them unusable when compared to markdown’s portability.
Really? I thought it was because core reST was too spartan, Sphinx reST had one non-embeddable Python implementation, and AsciiDoc took a long time to grow beyond just having a Python-based AsciiDoc-to-DocBook XML transpiler which leverages that AsciiDoc is designed to map cleanly to to DocBook XML as Markdown is to HTML. (And it still doesn’t have much of note beyond Asciidoctor, which is written in Ruby.)
Ohh, I was intrigued, but then… After reading for a while… I realized it was invented by the guy who sold his soul to the court of Steve Jobs. What next? Should I buy a Tesla?
That’s 20 minutes of my life wasted on something developed by someone I’ll never ever trust.
You mean Markdown? That’s why CommonMark (the dialect most renderers implement/superset these days) was developed. Because Gruber held onto the Markdown name when people wanted to standardize.
…and it’s not that different from reStructuredText and AsciiDoc. Here’s a guide explaining how to stick to the overlap between Markdown and reStructuredText so your document will render properly as either.
IMO Markdown is a fantastic middle ground between plain text and formatted text. Why? because it has ability to be BOTH at the same time! sweet spot. And you can read it as plain text as well. And render as rich text when needed. I fail to see the alleged “issue” with Markdown, really. My whole “second-brain” DB is stored in Markdown and thanks to that I was able to migrate it to different apps. Heck! I can even use multiple app frontends at once to view this content stored in .md. It’s fantastic.
To me, lightweight markups like Markdown, reStructuredText, and AsciiDoc are a solution to the problem WYSIWYG creates:
I want to see and edit the authoritative form of my documents, with nowhere for spurious formatting codes to invisibly hide to become a footgun later.
My mother uses LibreOffice and runs into strange bugs in documents interchanged with MS Word that I could fix in an instant if unpacking an ODT and debugging the raw XML weren’t so user-hostile, but I have no idea how to fix them when looking at the WYSIWYG interface.
In a sense, WYSIWYG is the “User-friendliness at the expense of a complex leaky abstraction” that characterized the heyday of Windows versions like XP and 7 (Windows is broken? Don’t try to fix it. Reinstall it.), while lightweight markup is the UNIX philosophy… treating leaky abstraction as an inevitability and trying to balance that against users who are willing to drift toward power user territory.
For people like my mother, I’d suggest the proper solution is something in the vein of LyX (where her only complaint is that you need to learn LaTeX to step beyond the WYSIWYM UI instead of having some kind of companion “template editor” abstraction) or WYMeditor. The key detail being how well LyX manages to achieve a compromise between “no control code is invisible” and “the user shouldn’t have to see source code”.
I’d say that, regardless of CommonMark lacking them, the rest of the world seems to be doing a decent job of unifying a set of extensions that can be toggled on and off in CommonMark parsers. In a sense, Markdown is Worse is Better-ing its way to the top in the same way the UNIX/POSIX/Linux is.
Modulo a few extension not yet implemented, if you ask a CommonMark parser to turn on all supported extensions, you tend to get CommonMark, plus the GFM-specified tables, strikethrough, and tasklist syntax, plus Kramdown’s footnote syntax, Commonmark-HS-Extensions definition lists, the admonition syntax that GitHub added but neglected to update their spec for, and a consistent syntax for subscripts, superscripts, header IDs (a type of internal link target), and inline math expressions that their manuals never told me the origins of.
Given that previous point about de facto standard syntax extensions implemented by common parsers, I think the only situation where it remains reasonably tool specific is the same one where it doesn’t matter what syntax you use, because the underlying tool is going to be HTML-sanitizing away the constructs they don’t want anyway… just like how WordPress comments predate Markdown and are written in a subset of raw HTML with the same unsatisfying omissions as un-extended CommonMark.
Every time one is simple enough that I don’t reach for inline raw HTML because the contents are too long/complex for any kind of lightweight markup to express.
(Seriously. My Chrismas wishlist contains a complex table full of details expanders and embedded Inkscape-annotated images to explain the DOs and DON’Ts of watching garage sales for System 7-compatible macintoshes.)
To clarify, I don’t mean all CommonMark parsers support turning on extensions. I mean that, when they do, they seem to walk their way up the same chain of de facto standard syntaxes, beginning with the ones from GitHub Flavoured Markdown.
For example, pulldown-cmark for Rust just added its support for Commonmark-HS-Extensions definition lists in 2025.
(And it certainly helps that a language as friendly (2) to exposing bindings for use by other languages, and being compiled to WebAssembly, as Rust is, has at least pulldown-cmark and Comrak and possibly more as CommonMark parsers with comprehensive support for said extensions.)
I used Markdown for saving a lot of documents (that no one else needs to read) for a few of reason: being plaintext it can be read anywhere without needing another tool, file sizes are small, and it can be edited anywhere. If I need to share an editable document I’ll use Word documents because that what people expect. Could I force myself to parse HTML in my head or write it when I just want to take notes or read something quickly? Yes, but that’s a higher cognitive load than the task usually merits.
I’m surprised no one has mentioned a benefit of plaintext, and thus markdown: it can be easily tracked by a version control system.