If it is worth keeping, save it in Markdown
119 comments
·February 22, 2025tengwar2
hakaneskici
Interesting. Why not HTML? Browsers have native basic WYSIWYG editing built in, and almost every screen we look at is nowadays HTML, including the code editor.
On a `<div contenteditable=true> element, calling document.execCommand('bold') will make selected text bold in WYSIWYG mode. See https://jsfiddle.net/z0umpb3x/12/ for the concept.
The main idea here is that I don't want to know any syntax like RTF, nor I want to use any tools.
inetknght
> Why not HTML? Browsers have native basic WYSIWYG editing built in
Can you point me to a page in Firefox that I can use offline to WYSIWYG edit a hypertext document without needing to use the developer console to edit raw HTML?
oneshtein
You can use this bookmarklet to create new pages:
data:text/html,<html%20contenteditable>
You can use another bookmarklet to turn existing pages or files into editable pages.
null
dangus
I'm not the parent commenter but I'm going to guess because HTML is horrible at WYSIWYG.
If your editing tool changes or if your switch editors, they will all botch your HTML anywhere you make edits.
RTF is basically "it just works," very much like "Microsoft Word Light."
assimpleaspossi
Your complaint seems to be about the editors, not HTML.
hakaneskici
Makes sense. I was thinking that browsers have native support for WYSIWYG editing and most browsers/apps are Chromium based; so how the browser handles HTML formatting should be stable for a single person scenario even across apps.
crossroadsguy
RTF isn’t a better option than MD, plaintext is. We start with the premise that we are talking about plain text, as in plain text, texts. But pretty soon we are into colours, then maybe images and videos, and then what all not.
But MD still is closest to plaintext because in most cases MD (or a similar scheme), even when not rendered, can be read easily in its plaintext formatting.
genewitch
The nextcloud Markdown editor shows a live view while you edit... Its called "Notes"
nicoburns
HTML is also worth considering. It's not quite as nice to write in as Markdown, but it's still pretty reasonable to hand write (or even read if it comes to it).
copperx
Is this sarcasm? or are we coming back full circle unintentionally?
nicoburns
It's not sarcasm. HTML is and always has been a decent format for hand-authoring documents. It's not as nice to use as markdown, but it does support more advanced use cases like coloured text.
And if you want an "archival" format that will stand the test of time it's pretty good (so long as your text encoding is readable, HTML will be).
ajxs
When I created the SSG I use for my blog, I tested a bunch of different markup formats for the article content, but in the end I settled on plain-old raw HTML. Over the years, I've needed to render so many different specific visual elements in the blog entries that if I wasn't actually using raw HTML, I'd probably be using raw HTML snippets all over the place anyway. For another medium I might choose a different markup format, but when it comes to writing content for the web, with HTML I know exactly what I'm getting every time.
caseyy
Markdown editors like Typora somewhat close this gap in functionality.
Evidlo
Just a note that the most common Markdown flavor (Commonmark) doesn't actually support frontmatter. The author is using presumably Obisidian-flavored Markdown (which is a mixture of Commonmark, GH-flavored Markdown, and Latex).
For file-tagging, I would consider TMSU [0] instead of writing bespoke tools. (ideally we would just use xattrs, but the world isn't ready for that)
[0]: https://tmsu.org/
thangalin
> Markdown flavor (Commonmark) doesn't actually support frontmatter.
That leads to mixing presentation logic (meta data, ToC) and content. When typesetting the Markdown, the ToC can be derived from headings and meta data should be isolated to avoid duplication. The following videos demonstrate some of the advantages to this approach:
* https://www.youtube.com/watch?v=cjQ-dle-tAE
* https://www.youtube.com/watch?v=3QpX70O5S30
See my editor's screenshots for more details:
https://keenwrite.com/screenshots.html
My FOSS editor is a cross-platform CLI and GUI application that replaces the shell scripts developed in my blog series about typesetting Markdown.
https://dave.autonoma.ca/blog/2019/05/22/typesetting-markdow...
jorvi
I like Commonmark but I wish it would have been more opinionated. They chose to allow two ways to do everything[0].
Making * always be used for bold and _ always for italicizing is so much clearer, and some Markdown flavors (notably WhatsApp) do this. So you only have to do *haha* or _haha_, which also makes italic-bold more _*intuitive*_.
Similarly they should have gone with one style of headings, probably with #.
This frees up more visual clarity. Because you are no longer using *** for bold-italic, you can use that for lines, instead of both --- and ***.
This then further frees --- up to be used for tables.
Although I imagine there's a decent subset of people that uses the alternate style of doing headings === and the 'normal' way of doing lines ---, which would have killed adoption.
And good luck convincing people to adopt a new variant at this point. "Commonermark"? "Peasantmark"? "Rabblemark" actually sounds decent.
Edit: actually, having checked the discourse around it a bit more, Commonmark wasn't created as "one Markdown to rule them all", but rather as "Venn diagram markdown with the most overlap".
Shog9
If you want strictness, use a linter or a pretty-printer that follows your preferred style. Adopting an opinionated parser means you can't lint or pretty-print input from those with different opinions (I do not like underscores for emphasis), and thus somewhat goes against the goals of TFA here:
> Markdown files are essentially plaintext with some extra syntax for common elements like sections, bullet points, and links. The format deliberately avoids precise control over display details like font selection. Following the rule of least power, I consider this limitation a feature.
One of my biggest ongoing frustrations has been MDX - a sort of markdown-and-JSX mixture whose spec is now in its third release and which has made very little effort to maintain compatibility with either CommonMark or itself. It is fairly strict and fairly elegant, and moving to a new version requires rewriting all previously-written documents to eliminate no-longer-supported syntax and re-training writers. Both of those things are miserable tasks; it has absolutely killed any tolerance I might have had for a stricter parser.
dqv
I'm surprised they didn't make a conversion tool to do MDX(old) -> AST -> MDX(new). The library support is there, but it doesn't look like anyone has created a tool to do it.
everybodyknows
> ... new version requires rewriting all previously-written documents to eliminate no-longer-supported syntax and re-training writers
Wonder if any of the LLMs could do that for you?
null
hartator
The only drawback of Markdown is images.
GitHub-flavored Markdown is so popular because you can really easy inline them. You don't have to worry about storing them, linking them correctly, and you can even paste to the Markdown field.
There is no elegant solution like this in actual Markdown.
darkteflon
I would add tables to that. Obsidian has some nice extensions to make working with tables easier, but it always feels janky.
hartator
Yeah, what people like about Markdown is basically regular text.
The formatting is interesting, but it’s not revolutionary or anything.
null
jon_richards
The killer app for markdown would be a collaborative editor that displays the raw markdown and formatted markdown side-by-side and makes both sides editable. Tech people can use `#` and `*` on one side for formatting, product people can use normal text-editor buttons like "header1", "italics", etc.
philips
Someone is sort of building this on Obsidian: https://screen.garden
packetlost
yoooo this is sweet. Been looking for this for awhile.
r3trohack3r
I built this in college, but the code is lost. It was a week or so of hacking. I believe in you.
IIRC the trick was to get a pipeline for Markdown to HTML, render it into a WYSIWYG editor, then convert the HTML to an AST, and walk that to generate the markdown. I had to “format” both the markdown and html on each render (bidirectional round trip render) because parsing/gen wasn’t whitespace stable.
dtkav
Here's a comparison chart of collaboration/teamwork plugins in Obsidian.
https://system3.md/observatory/categories/collaboration-team...
Peerdraft, Relay, and Screen Garden are all based on CRDTs, and Obsidian is also currently working on native collaboration.
(disclaimer: I work on Relay)
jkingsman
It's not collaborative, but this is what I love about Typora[0]. Click into a styled area and the styling becomes visible. Click out, and you just see the final styling.
jxjnskkzxxhx
Sounds like an obsidian plugin.
philips
Someone is building that: https://screen.garden
mock-possum
Notepad++ and VSC both have plugins for this.
They’re fine.
eviks
This is a very common mistake wasting half your screen, it can't be no killer app
pphysch
Why does it need to be side by side? Just let each client choose WSIWYG or raw.
david422
When writing in text mode so that you can see what you are generating. Wouldn't really need it the other direction though.
renewiltord
You can do that in IntelliJ. If there's a way to control a tab on a browser you could do that too. When I was writing my thesis, I would have `inotifywait` running on one side and when it detected the file had changed it would run the entire `pdflatex` + `bibtex` pipeline the 6 times or whatever it needed and Evince would hot-reload so I had a live preview. I'm sure a browser can do the same with some command.
normalaccess
I love markdown and use it for all my notes, however it really needs a native way to underline. I have been converting some older books and lectures to markdown and underline is used all the time.
If anyone has a good solution I'm all ears.
fsckboy
>converting some older books and lectures...If anyone has a good solution I'm all ears.
I don't know if this helps you, but you said "older": in the 20th century world of typewriters--which had no italics--underlining was used as a substitute for italics. Transforming underlines to italics or going the other way was considered normal. You wouldn't use both in the same document.
voltaireodactyl
I love the Fountain spec for exactly this reason. I primarily began using it since it’s Markdown for screenwriting, but it has bold, underline, and italics along with the usual markdown stuff like comments etc. I find it to be by far the best way to write plaintext anything other than code. It’s also a bit more opinionated than Markdown which I highly prefer.
ambivalence
Markdown is plaintext so you decide what it means. I personally write *italic* and **bold**, so I can use _underline_. Most Markdown to HTML converters would make the last example into italic, but you can customize many of them.
Commonmark doesn't even mention "bold", "italic", and "underline". It just says "emphasis" and "strong emphasis". You can style it however you want.
paulryanrogers
This kind of undercuts the advantage of a semi-universal format. Though I'd agree underscore wrappers are quite reasonable and natural.
alpaca128
The solution are HTML tags like <u></u>
Tagbert
it might depend on what you want to do with the underline. Does it just indicate some kind of emphasis?
Could you use the convention in your documents that "_" is the underline delimiter? I know that the default is to render it as italic/emphasis but that is just a decision at rendering time. The semantics of emphasize/underline could easily overlap.
Of course if you want 3 levels of emphasis with bold, italic, and underline, then yes you need to look elsewhere.
Markdown isn't really a formatting tool. it is a way to structure text in the minimal way that a person would interpret it and a machine could render it.
grimui
Not the best solution but you could use the HTML underline tag
asielen
100% agree. I've been using markdown for a few years after moving away from proprietary note taking apps. Although this has led to me developing my own short hand for many things in my notes. And have been looking at a way to integrate a to-do list with my notes with some Python scripts.
So while my notes may rely on some personal scripts to get there most value out of them, I strongly value that they are still plain text and I can always move them into a new workflow if I need to.
Onawa
Maybe consider Quarto? Free and open source, integrates Python scripting directly in Markdown and/or able to call from separate scripts.
asielen
Thanks for the recommendation! Sounds interesting
darkteflon
Love Quarto. I write all my notes, presentations, blog posts, memos, etc in .qmd files. For non-technical stuff I use Obsidian to author (there is an extension which tells Obsidian to treat .qmd as ordinary markdown - ie ignoring the additional Quarto frontmatter and so on), then for everything else I use VS Code with the Quarto extension and just render out to the display format I need. I really appreciate that it’s built on Pandoc and it means I can just use one format and one set of tooling for everything.
xenodium
I built Markdown to web, drag and drop solution: https://lmno.lol
Here's a demo https://www.youtube.com/watch?v=SykbiVweYH8
jazz9k
Obsidian is the killer app for this. I spent a month converting around 3 years of security notes to markdown and now use obsidian to search/archive everything.
yawnxyz
well, I wish I could have saved all my old Flash sound design and game experiments to Markdown, and still be able to play them
Beijinger
Hm. Great.
I save everything interesting. I have a data folder with letters a-z in it. Something interesting might be saved in HTML or PDF under data/a/ai/programming
Folders have a problem because the same thing could be saved under data/p/programming/ai
But it is a start. For everything else, there is recoll. https://www.recoll.org/
hamsterbase
When it comes to web archiving, I've found that Markdown has some real limitations. Sure, it's great for basic text, but it struggles with things like embedded content and non-standard layouts. Try archiving a Twitter thread or an app-style webpage in Markdown, and you'll see what I mean. It just doesn't capture the full picture.
That's why I've come to prefer formats like webarchive, mhtml, or single HTML files for archiving. They're incredibly faithful to the original content - you get almost perfect rendering of the original page, complete with styling and layout. Plus, they can capture stuff behind paywalls or on logged-in pages, which is a huge plus.
The real challenge, though, isn't just about saving the content. It's about making that saved content useful. These archive formats are great for preservation, but they can quickly become a mess of unorganized files that are hard to search through or make sense of.
I think the key is finding ways to organize and interact with these archives more effectively. Things like full-text search across all your saved pages, the ability to add notes or highlights directly on the archived content, and smart tagging systems could go a long way. And it'd be really powerful if we could integrate these archives with other knowledge management tools we use.
I develop a tool called HamsterBase that seems to address a lot of these issues we've been discussing. t's a local-first app. That means all your data stays on your own device - no need to worry about your personal archives being stored on someone else's servers. There's no sign-up or registration required, which is refreshing in today's cloud-centric world.
thangalin
> [Markdown] struggles with things like embedded content and non-standard layouts.
I don't share that experience. I typeset all these documents using Markdown with pandoc's div extension, transformed into XHTML, and then passed to ConTeXt:
* https://impacts.to/downloads/lowres/impacts.pdf
* https://dave.autonoma.ca/blog/2020/04/28/typesetting-markdow...
* https://pdfhost.io/v/4FeAGGasj_SepiSolar_Highlevel_Software_...
From XHTML, the document is transformed into TeX statements, which opens a world of possibilities. In the following video, custom styling is applied to nested contents:
ambivalence
I wholeheartedly agree with this post. I also keep my notes in Markdown, I also have plenty of Python scripting around them, including automatic publishing of my website.
I use FSNotes today on macOS and iOS. Both apps are open source, both use well-structured .textbundle directories that separate Markdown content from JSON metadata and binary attachments. Synchronization happens through Git. It's a very powerful combination.
Ironically, I wrote a blog post some 8 years ago about this very subject. That blog post is now offline.
ydant
I appreciate the mention of FSNotes (and in turn textbundle). Somehow, despite trying tons of note taking apps and formats, I don't remember ever coming across mention of this format specifically.
My biggest beef with org mode and all of the markdown apps I've tried is the asset management problem. For me screenshots are almost as important as the text part of the note, and are usually strongly tied to a single note. I've taken to using apple notes at work just because it "solves" that well enough, but I'd really prefer to work in markdown/plain text (except for the images).
The other major alternative to consider is RTF. I standardised on that about 10y ago, planning for a 30y horizon. It is a more complex format than Markdown, still text-based, but biased towards WYSIWYG presentation and editing, while Markdown is usually not WYSIWYG in the editor. Both formats suffer from a lack of standardisation, though Markdown seems to have more problems in practice - I've never had an issue caused by RTF incompatibility. Both are very widely supported. Both formats are very widely supported and it can reasonably be expected that this will continue.
I prefer RTF for two main reasons:
* I can't express simple formatting such as "make this text red" in Markdown. No, I don't mean "accentuate this text and leave the decision on how it looks to someone else", I really do mean "make this text red". I do a lot of public speaking, and I want to keep to certain conventions which are easy to read fast.
* Most of the time I am writing text, not reading a version after it goes through a formatter, so I prefer to see it formatted on screen. That's really a limitation on Markdown editors, but it's almost universal so for my point of view, it counts.