> If I want to see the original Markdown syntax, I should be able to switch to that view just as easily.
This doesn't really map well to existing document opening conventions, so the author's hypothetical built-in Markdown viewer/editor doesn't really fit into any existing system app. For example, if Apple modified TextEdit.app to open Markdown files in the same way it handles RTF documents, it would cover the formatted display case, but not editing the source. They would have to add some third mode (or build an entirely separate app) to handle switching between Markdown source and formatted views, deal with displaying malformed syntax, etc. Not to mention handling the various differences between Markdown flavors.
Then some sane styling defaults, which you can change globally, on a per folder and on a per document basis. Perhaps the option to include some stationary backgrounds for PDF rendering, and I think you have touched upon 95% of the document editing needs.
TextEdit already lets you switch between rich and plaintext mode, so there's a precedent. Maybe a "view without formatting" toggle in the format menu that's only enabled or visible for markdown files. The ability to open markdown documents in source view by default could be a checkbox in the Open and Save tab of the TextEdit settings window.
> Not to mention handling the various differences between Markdown flavors
Funnily enough, I was looking for Python markdown to HTML rendering library, and the author of one of the biggest two closed a bug on me reporting a minor incompatibility saying "that is GitHub format, we don't support it, we only support CommonMark, GitHub format is non-standard and broken".
Obsidian's edit mode is 99.99% formatted. It only omits HTML symbol shorthands like "→". Other than it's completely formatted, WYISWYG as you type fashion.
Reading mode is more like a Read Only toggle on a floppy disk. Prevents accidental edits.
I was talking about Source Mode, you seem to be talking about Live Mode, which indeed, is editable WYSIWYG
Maybe your comment needs a little clarification?
Of course, there are services that do that for you, ranging from Hugo to Obsidian Publish. But they all add a level of complexity that you have to manage.
Also, this makes user-level styling much simpler. This is what any “Reading mode” does, but without reverse-engineering the content from a soup of tags and classes.
What I imagined is browsers rendering the content with headings, quotes, etc. Browsers could have some default styles to render MD files. Those styles could be configurable the same way “Reading mode” is usually configurable.
The plain unstyled rendering of strings of text is, of course, available even now. That's why I'm saying this needs a browser-level support.
> you only need a very simple script to convert md to plain html
I get, that it feels simple compared to other software. Even more, MD was designed specifically to be simple!
But if you think about it, this is still too much complexity to just share some text.
With native browser support, you could run zero commands to build a website.
I think this is mostly important for regular users, not developers. Imagine if creating a Word document would require the same level of complexity as building a web page: I doubt that the format would be so popular as it is nowadays.
I am not sure its that important that its a default. Markdown is primarily and editable format that is easily converted to a readable one - its the inverse of PDF which is a readable format that is hard to edit.
We need a better markup language.
I'd settle for just saving CommonMark files with a dedicated file extension, most people think of CommonMark when they say Markdown anyway.
Yet as you note later there is no such thing as a singular markdown. So why would time do magic here? There is nothing remarkable about bad underspecified system suffering from incompatible variety for decades, computers are littered with examples of those
> One of the original ideas behind Markdown was that a document should remain readable even before a computer interprets its formatting
Which was never true since it includes HTML which you criticize in the very next sentence
> We have spent decades dealing with document formats that behave differently depending on which application created them, which version of the software is installed and which operating system is trying to open them. Markdown should be an opportunity to move in the opposite direction.
Weird, MD has all the same issues, why would it present any opportunities?
ez, wish the browsers had nice rendering out of the box and registered themselves as a handler though
Oh, but Markdown isn’t simple. Easy it is, certainly, but simple it isn’t because of one feature: being able to embed HTML. So the semantics of Markdown subsumes the semantics of HTML, which has a _huge_ spec.
What one’d like in many cases would be a Markdown-without-HTML-embedding. But that’s no longer Markdown.
I felt the same but if you put it into Claude code Opus 5.5 can build you a program that will open faster than anything you’ve ever used before if you ask for it. I asked for it and it’s instantaneous. Faster than literally any other macOS app.
It opens and displays a markdown file faster than bitwarden’s chrome extension displays its fill UI.
The future is almost here. Formats and so on are on the threshold of irrelevance in the next few years for this kind of consumer use. It’s hard to even tell if the time it takes us to summarize a text will be the time a future agent takes to write a specialized program that extracts what you need from the file. “Native” support will soon be irrelevant.
Even my solution is yesterday’s solution.
Doesn't look like this to me.
The main point of the essay is that MD files should be supported on an OS level. This way, you could share an MD file with anybody, and it will “just work”.
You could develop your own viewer, but this will not solve the problem of “just working” for every user. Because most users wouldn't install some app just to open the file you shared with them. The same way you don't expect users to install any software to open websites, images or PDFs.
The OP is arguing that something should work by default without any configuration needed, and you're talking about building a bespoke tool.
Android doesn't come with a text editor by default but there are loads of options out there. Same goes for any docx or even PDF if you don't have Google Drive installed.
The fact that a file can't be opened as plaintext in a plaintext editor is not a problem with Markdown, it's an OS problem that effects any file you'd want to open as plaintext.
Just opening in notepad by default works fine. The point of markdown is that it doesn't need rendering to be readable. If you need more, you already have a preferred Markdown IDE setup anyway.
Markdown is pretty terrible as a rendered format anyway. The standard for Markdown itself is extremely loose so we invented several types of Markdown, indistinguishable from each other with slightly different features and syntax, to cover the loose standard. CommonMark isn't Markdown yet I see nobody saving files as .cm to actually indicate what kind of Markdown they need.
This is a major annoyance in messaging apps, slop tooling, and of course git GUIs. Building a standard viewer will bring all of those problems to the operating system, and for what? To annoy the people who already have a Markdown viewer of choice?
I think the point being made is that users who do not care about Markdown will receive Markdown files, and it should be trivial for them to open and view them.
Yes, the article also states “If I want to see the original Markdown syntax, I should be able to switch to that view just as easily”, which isn’t necessary for that use case, but I still think that’s a point the author makes.
1. There’s no acknowledgement of the rich ecosystem of markdown dialects, which add all sorts of incredible features as simple as inline citations and as complex as full roles and directives. They all need highlighting.
2. There’s author claims to like markdown, but then it becomes clear that they don’t like markdown itself, they just like it being behind a rendered WYSIWYG editor. Which… :( headers should look like headers and tables should look like tables, yes, but not at the cost of removing any of the syntax characters! If you do, you’re sacrificing the whole point of the format: ease of modification.
Clearly their heart is in the right place, though. I absolutely loathe sites that don’t support markdown; there is *zero* reason not to do something _this_ important! ~~I dare say it would be something that the three mods and their uninvolved monarch should go to bed every night feeling ashamed of…~~
It's the opposite, you remove the major challenge in modification- change one char and break your whole table. It type an extra backtick and now paragraphs of text are misformatted. Add/remove a column? Ha-ha, where did you get so much time to waste? Join two cells? Oh, that's too complicated
Search and replacea phrase? Impossible to find, there are formatting markers between words.
The OS should be able to natively open plaintext. The joy of markdown is it still largely works in plaintext.
Except it doesn't because it isn't, the challenges above are from editing raw. There is no joy in reading/editing anything non-primitive in MD
Shockingly, I could only find about 3, and all sucked in their own special way.
I have the simplest of requirements: just format it and show it like a PDF. Either the app doesn't remember its position and always restarts in an awkward landscape format, or it insists in showing a "file tree" side bar, no simple file viewer.
How do I teach someone who never opened anything besides excel, word, and powerpoint about markdown? to them the document file is just a document and it opens in word that's mostly what they know for this audience.
⟩ Write me a Markdown file viewer for ${OS} that shows Markdown files as formatted documents by default. A button should toggle between the formatted view and the raw Markdown file as plain text. Work the task to completion and make no mistakes.