HTML vs Markdown: Why Notidian Chooses HTML for Notes
For years, Markdown has been the go-to format for note-taking. However, as Notidian evolves, and as users demand more flexibility, HTML opens possibilities that Markdown struggles with.
HTML vs Markdown: Why Notidian Chooses HTML for Notes
Based on “File over App” by Steph Ango: the idea that the files we create should be durable, controllable, and future-proof.
Introduction
For years, Markdown has been the go-to format for note-taking, blogging, documentation, and lightweight content. It’s simple, human-readable, easy to write by hand. However, as Notidian evolves, and as users demand more flexibility, extensibility, and interoperability, Markdown’s limitations start to add up.
HTML, by contrast, is more expressive, standard, and future-proof. It opens possibilities that Markdown struggles with. Below, I compare the two, draw from the File over App philosophy, and argue why Notidian might choose HTML as its canonical note format.
File Over App: Philosophy First
Steph Ango’s File over App reminds us:
- Digital artifacts are only as valuable as their openness and longevity.
- Applications are ephemeral; file formats are what persist.
- If you want your writing to still be readable years or decades from now, it should not be locked into proprietary or narrowly supported formats.
Markdown partly aligns with this: it is plain text, widely supported, simple, and portable. But does it go far enough? As we’ll see, there are cases where Markdown ends up becoming a patchwork — something like “Markdown + extra tags or custom syntax” or embedding raw HTML anyways — in order to push past its limitations. At that point, the simplicity advantage starts to erode.
Key Differences: HTML vs Markdown
Here are core dimensions in which HTML is stronger (or at least different), and where Markdown shows weakness.
| Dimension | Markdown Strengths | Markdown Weaknesses / Workarounds | HTML Strengths |
|---|---|---|---|
| Readability & Simplicity | Very lightweight. Humans can read/write without tools. | Complex content (tables, embeds, interactive blocks, drawings) often need workaround syntax. Some flavors differ. Custom syntax or plugins break portability. | Full semantic structure; whatever you write is valid HTML; browsers and tools understand standard elements. |
| Expressiveness / Layout / Styling | Basic headings, lists, blockquotes, code, maybe tables depending on flavor. Styling is minimal; layout control is weak. | To get styling/layout you often embed raw HTML inside Markdown; or use flavor-specific classes or front-matter; or rely on extensions. These reduce portability. | Full CSS / Tailwind / custom classes / responsive design etc. Rich media, custom components, canvas, etc., all possible by default. |
| Interactivity and Rich Media | Limited. Embeds may need raw HTML; drawings, interactive components, web components, etc., mostly outside core MD. | Plugins or conversion tools needed; can get messy. Different Markdown parsers treat things differently. | Natively supports scripts, iframes, canvas, web components. Dynamic components can live inside HTML. |
| Portability and Longevity | Pretty good. Plain-text can survive many tools. Many editors support Markdown. | But markdown flavors differ; custom extensions may not be supported elsewhere. Some tools strip or misinterpret custom syntax. Conversion between flavors can lose information. | HTML is a W3C standard; browsers will support HTML for decades. Even very simple HTML will render somewhere. Converters exist (HTML→Markdown, HTML→PDF, HTML→DOCX etc.). |
| Editing Tools & WYSIWYG | Lots of Markdown editors; some WYSIWYG MD-editors. But complex elements handled inconsistently. | Visual editors may limit what markdown flavor they accept. Extensions complicate editing. | Plenty of mature HTML visual editors (TinyMCE, CKEditor, TipTap etc.), block editors, web components. You can build visual editing that works on standard HTML. Enables full control. |
| Conversion & Interoperability | Markdown → HTML is easy. HTML → Markdown less so; some information (classes, inline styles, custom components) may not map cleanly or may be lost. | Markdown with embedded HTML starts to become less portable. If you rely heavily on flavor-specific syntax, some readers will break or misinterpret. | Since HTML is richer, converting down to Markdown is possible (with tools), when you accept losing some fidelity or treating style/class info as optional. But as canonical source, HTML gives maximum fidelity and flexibility. |
Risks & Trade-Offs: Why Markdown Still Has Appeal
To be fair:
- Markdown is easier for most people to pick up, write quickly by hand, especially for plain text content.
- Smaller files, simpler syntax means editing by hand is often faster.
- For simple note content, Markdown is sufficient, and the overhead of HTML seems overkill.
But the moment you want to embed charts, drawings, canvases, custom styling, responsive layout, or interactive elements, Markdown often ends up forcing you into its own “escape hatches” (raw HTML, custom syntax), which damage portability and consistency.
Why Notidian Might Choose HTML
Putting together all this, here are concrete reasons Notidian might choose HTML as its canonical note storage / rendering format:
1. Maximum Expressivity
Users will want more than simple headers, lists, and code. Notidian aims to support drawings, canvases, embedded rich media, live components. HTML handles that natively.
2. Consistency Across Tools & Future Editors
If the note is stored as clean HTML, any editor that supports HTML or a visual WYSIWYG paradigm can open/edit/display in consistent ways. There is no concept of “flavor mismatch” or unsupported extension (so long as custom parts are clearly declared).
3. Robust Longevity / Data Control
Following File over App, the faster evolving pieces are the apps/editors; what matters is the durability of the files. HTML is a web standard. Plain HTML files can be opened decades from now in browsers, tools, even basic viewers.
4. Better Styling/Theming/Cross-Device Rendering
Tailwind or other CSS frameworks can be baked into the templates. Notes can adapt to mobile, desktop, dark mode, etc. with consistent layout/typography/spacing — unlike in many Markdown environments, which differ in rendering.
5. Modularity and Composability
Notes can embed custom components, separate drawing data, table data, etc., using semantic HTML tags or web components. This maps well to modular file structure. Updates to one component don’t break the rest of the HTML.
6. Conversion & Export Flexibility
As canonical source, HTML can be converted to Markdown (losing non-portable bits if needed), to PDF, ePub, DOCX, etc. If desired, Notidian can also support Markdown import/export, but without compromising on HTML being the ground truth.
7. Avoiding Franken-Markdown
Many Markdown engines already accept raw HTML or plugin syntax. If you rely heavily on that, you’re no longer in pure Markdown; you create a hybrid or “markdown + custom HTML.” That becomes brittle: some readers will strip out unknown tags; others will mis-interpret syntax. Choosing HTML avoids that ambiguity from the start.
Possible Design: Hybrid or Progressive System
To get the best of both worlds, Notidian can design a workflow where:
- Users write in a visual HTML editor (or a “markdown-lite” editor that outputs HTML under the hood).
- The stored note is clean HTML + optional modular/separate files (drawings, attachments, etc.).
- Provide an HTML template/shell that includes styling (Tailwind or CSS variables), maybe theme support.
- Support converting to Markdown for export or interoperability when needed, with clear loss of fidelity documented.
This lets users who love Markdown keep using something simple (for simpler notes) but ensures that complex content and future features won’t become a tangled mess.
Conclusion
Markdown has been and remains useful. It’s simple, portable, familiar, readable. But its simplicity is also its constraint.
HTML offers far deeper expressivity, more styling and layout freedom, better long-term standards support, and fuller control over what a note can be. If Notidian wants notes to be powerful artifacts (not just simple text), HTML is a strong choice for the canonical format.
True durability comes from giving users control of their files, storing content in standard, open formats, and minimizing reliance on proprietary or “flavor-locked” syntaxes. If the files themselves are HTML, Notidian is making a statement: your notes are yours, and they’ll be readable, editable, beautiful, and useful far into the future.
Join the Discussion
What are your thoughts on HTML vs Markdown for note-taking? We’d love to hear your perspective. Join us on GitHub or reach out to discuss the future of digital note-taking.