Markdown was common enough even in 2022 that this article, for example, is still written in Markdown.
But should Markdown be the default technology for text editing? The answer is no. I found a nice article of Thoughts On Markdown that criticizes the no-brain use of Markdown as a technology selection. It mentioned that Markdown has drawbacks in standardization, structuring, and componentation. If you really want to make a modern text structure editor, don’t use Markdown.
An overview of the
Markdown has become so widespread that it has even become our second language. Markdown’s original parser was written and released in Perl by John Gruber in 2004. At the time, Markdown had only one purpose: to facilitate web writing.
Web writing must be based on the HTML specification, which is too expensive for most people to learn, so Markdown is a text-based syntax that is easier to understand, or less expensive to learn, or even silly. To parse this syntax, you need a parser. This syntactic text is eventually converted to HTML.
With digital development, Markdown is no longer suitable for today’s writing scene, for two main reasons:
- Markdown is no longer suitable for today’s interactive, content-shaped writing.
- Markdown’s text-only development experience no longer meets the increasing needs of modern developers.
First of all, I will introduce Markdown.
The core idea of Markdown
The biggest advantage of Markdown is that it’s easy to get started without having to deal with complex nested statements like HTML (although HTML is also at the bottom of the contempt chain for programmers). The original article abstracts three advantages:
- Appropriate text-based abstractions. While HTML and even code are text, the word “appropriate” is important, meaning that any text can be a Markdown, describing professional structure with a little markup, and learning costs are minimal.
- There are plenty of ecological tools. Such as syntax parser, highlighting, format conversion, formatting, rendering and other tools are complete.
- Edit content for easy maintenance. Markdown, for example, is easy to store as source code, while rich text in other formats may not be easy to maintain in source code.
If you compare Markdown to a database table structure, the cost of understanding the database is simply too high.
However, in today’s era of back-end as a service, database access is becoming easier and easier, and there are even a large number of SAAS products such as AirTable that can quickly transform structured data into applications. In fact, after getting into contact with these products, I really realize how important structured data is to developers. Markdown is fine for writing articles, but its use to express logical structures is a surefire recipe for disaster, and the author’s team was forced to solve a host of problems that far exceeded their expectations.
If you really want to go deeper into Markdown, you must use syntactic extensions to satisfy your custom appeal.
Markdown syntax extension
Originally, Markdown syntax did not support tables. If you wanted to draw a table with Markdown, you could only use native HTML tags:
, of course, this also shows that Markdown is essentially a handy syntax for HTML that can be used as HTML.
However, not all creative platforms support the
syntax, and I am often troubled by the fact that some platforms block native HTML syntax to ensure the so-called “security” or “consistency” of content experience. In order to make up for the lack of table drawing ability, Some custom syntax is often supported, or worse, not, which brings us to Markdown’s syntax extensions.
What are the extensions of Markdown? For example, the multiMarkdown, commonMark, and Github converged Markdown.
For example, the standard MD format requires two Spaces at the end of the first line, but GFM removes this restriction. While this is more convenient, it exposes specification inconsistencies between platforms, making Markdown cross-platform almost impossible.
Do we have enough energy to learn and memorize the grammar developed on various platforms? First of all, whether it is worth learning or not is a question. Why does an online writing platform need to take up the learning and cognitive costs of writers, instead of trying to simplify the writing process? Therefore, grammar expansion seems very good, but in the writer’s point of view, or the whole Internet platform, this non-standard approach must be unreliable, no user feel that your platform is qualified to “teach him grammar”, unless you are wechat, Dingpin or Feishu.
The point of the article is:
- As a writer, you don’t know which Markdown grammars are available and which are not.
- There are some fuzzy areas in the standard specification that lead to a lot of complications for developers to implement.
Also mentioned a grammar development causes the original understanding of higher costs of example: custom mrkdown slack platform does not support [link] (https://slack.com) way to describe the link, and use the < link | https://slack.com > syntax.
In conclusion, Markdown syntax expansion should be a good thing, but the fact that there is no standard leads to the flowering of standards, making Markdown a state where there is virtually no standard, which has more drawbacks overall.
The user base for Markdown
Markdown’s own positioning is not clear, which also leads to the persistent reluctance to determine standardized grammar.
Initially, Markdown was a markup language for people familiar with HTML, but it has since shifted to developers who want to expand the syntax to accommodate more complex usage scenarios. Markdown’s native syntax cannot accommodate increasingly complex visual presentation forms.
Markdown is now mostly used by developers and people who are interested in code, not that developers love it, but that Markdown’s audience has narrowed. Today, any document editor for non-developers will not use Markdown, but WYSIWYG (What You see is What you want).
The transition was painful, but it is now common knowledge that rich text editors should not use Markdown syntax, but WYSIWYG mode.
From paragraph to block, from article to application
Simply put, Markdown is no longer suitable for the current rich HTML ecosystem. Markup languages that can easily describe paragraphs have to be introduced when interacting with component blocks, such as MDX, but such solutions are only suitable for programmers and are not portable at all.
Web browsing has also evolved from simple articles to holistic applications with complex layouts, styles, and interactions that if you try to extend the syntax to support Markdown, you might as well go straight to native HTML.
The need for structured content
From a programming perspective, this is “component reuse”. Markdown’s native syntax does not allow content to be reused, and if it had to be reused, it would have to be repeatedly written everywhere, which would result in significant synchronization costs.
For example, Jekyll introduced the concept of FrontMatter to create reusable variables:
---
food: Pizza
---
<h1>{{ page.food }}</h1>
Copy the codeWYSIWYG editors should not use HTML as an underlying data structure
Just because browsers really use HTML as the underlying data structure doesn’t mean that wySIWYG editors can do the same, which is why browsers can only provide output from source code to UI, not reverse input from UI editing to source code.
Because the user’s input does not correspond to the HTML in a one-to-one way, there are a lot of fuzzy areas. For example, if the current cursor is between bold and fine text, should the next input be bold or not? Bold labels are not visible from the UI. Also, if the HTML is redundant, the cursor position is already covered by several layers of bold tags, but because the cursor area is covered by another style tag in bold mode, when typing again, it may jump out of the coverage area and become bold again. Does this process meet the user’s expectation? Technically, this complex tag structure is almost impossible to handle because there are so many combinations.
Most modern editors store data structures in JSON format because of its structure and ease of retrieval.
Markdown, too, has its own HTML-like ambiguities and is not suitable for storage as an underlying data structure.
Intensive reading
There are few articles criticizing Markdown, and it was only after I read them that I realized how flawed Markdown was. Let me talk about Markdown’s shortcomings based on my own experience.
Does not support rich interaction helplessness
Markdown can only support simple HTML structures and cannot describe logical blocks. Most of Github’s Readme uses images for these functions, including status cards, build results, and personal information cards. Unfortunately, the interactive capabilities are still too weak. I think Github will someday introduce something like blocks. These blocks can be inserted directly into Markdown as an interactive element.
Does the MDX address Markdown’s pain points?
MDX, seemingly perfectly compatible with JSX and Markdown, has been a lifesaver for me, but portability is a pain point. Components can only be used on the site you deploy, and if you want to publish to another platform, it’s impossible.
And that’s just my point of view. If you look at the Markdown ecosystem, MDX is a community of programmers for users and doesn’t solve its mission of “making web writing easier”, and programmers will eventually abandon MDX to develop WYSIWYG editors to solve the problem.
There are logical problems with Markdown to HTML conversion
Markdown is essentially a text-representation structure that is separate from HTML, which looks elegant when decoupled, but can actually cause quite a few inconsistencies.
For example, what happens when you hit multiple Spaces in a row? Markdown becomes a reference block, so how do you display multiple Spaces? Who knows, you may need to check the additional syntax provided by a particular platform to do this.
This is generally easy to use, but the details are not customizable or even out of the user’s control, which can hurt users already heavily using Markdown and either force them to invent new syntax to fix these bugs or abandon Markdown altogether.
Inadequate structuring ability
It looks like Markdown’s syntax is structured, but in fact Markdown’s structuring is not binding.
JSON, by contrast, can be expanded to a Json-schema.org/ structure that can even reverse a full form application because JSON can be defined at every Key and level, with structure first and content second.
Markdown, on the other hand, has content first, then structure. For example, we can write any HTML tag anywhere in Markdown, or any paragraph. These contents cannot be serialized, even if we parse them into JSON according to the browser’s rules for parsing HTML, we cannot easily extract information from them.
The fundamental reason behind this is that Markdown itself is positioned as “almost the result of UI rendering”. In fact, browser UI rendering requires a set of strict HTML syntax, because THE UI and the syntax behind cannot be mapped one by one. A stable rendering logic can only be derived from the source code to render. You cannot derive the source code from rendering. Markdown itself is positioned almost as close to rendering results, so the lack of structuring ability is a natural problem.
conclusion
I still remember that Markdown was used for editing in the early internal trials, but it soon removed the Markdown editing portal, which caused many developers’ dissatisfaction, and even some Markdown editing plug-ins were developed, which were once very popular. But as we’ve grown accustomed to wySIWYG editing, the only thing Markdown has left us with is shortcuts, such as ### space to generate H3 header paragraphs, and the Cursor editor has gone further and further into the rich interactive component block. If Markdown had locked the technology down, I couldn’t have had the editing experience I have today.
All programmers love Markdown, but it is not everyone’s idea to look ahead to its limitations in the current stage of Internet development and design a set of structured data to replace Markdown’s structure. We need to look at technology in a dynamic way and put aside the prejudices of technical people. Give up favoritism to product positioning.
The discussion address is: Close reading thoughts on Markdown · Issue #397 · dT-fe /weekly
If you’d like to participate in the discussion, pleaseClick here to, with a new theme every week, released on weekends or Mondays. Front end Intensive Reading – Helps you filter the right content.
Copyright Notice: Freely reproduced – Non-commercial – Non-derivative – Remain signed (Creative Commons 3.0 License)