Intensive reading "Thinking about Markdown"

Markdown is very common even in 2022. For example, this article is still written in Markdown.

But should Markdown be the default technology of choice in text editing? the answer is negative. I found a good article Thoughts On Markdown mindless use of Markdown as a technology selection, it mentions that Markdown has flaws in standardization, structure and componentization, if you really want to do a modern text structure Editors, don't use Markdown.

Overview

Markdown is so widespread that it has even become our second language. The earliest parser of Markdown was written and released by John Gruber based on Perl in 2004. At that time, Markdown had only one purpose, that is, to facilitate network writing.

Web writing must be based on HTML specifications, and HTML specifications are too costly for most people to get started, so Markdown is a grammar created based on text that is easier to understand, or cheaper to get started, or even foolish, and parsing this grammar requires Equipped with a parser, this grammatical text is finally converted into HTML.

With the development of digitalization today, Markdown is no longer suitable for the current writing scene. There are two main reasons:

1. Markdown is no longer suitable for the current rich interaction and content format writing.
2. The Markdown plain text development experience no longer meets the ever-increasing experience demands of contemporary developers.

First, let's start with the idea of Markdown.

The core idea of Markdown

The biggest advantage of Markdown is that it is easy to use and does not need to touch complex nested statements such as HTML (although HTML is simple enough for programmers to be at the bottom of the contempt chain). The original text abstracts three advantages:

1. A suitable abstraction based on text. Although HTML and even code are text, the word "appropriate" is very important, that is, any text can be Markdown, as long as a little mark is added, it can describe the professional structure, and the learning cost is extremely low.
2. There are plenty of ecological tools. Such as syntax parser, highlighting, format conversion, formatting, rendering and other tools are complete.
3. Editing content is easy to maintain. For example, Markdown is very convenient to store as source code, while rich text in other formats may not be convenient to maintain in source code.

If you compare Markdown with database table structure, the cost of understanding the database is really high.

However, in today's backend-as-a-service era, database access is getting easier and easier, and there are even a large number of SAAS products such as AirTable that quickly convert structured data into applications. how important. Markdown is good for writing articles, but when it is used to express logical structure, it will inevitably lead to disaster.

If you really want to go deeper and deeper in the pit of Markdown, you must use syntax expansion to meet custom demands.

Markdown syntax extension

Initially, the Markdown syntax did not support tables. If you want to draw a table with Markdown, you can only use the native HTML tag: <tabke></table> , of course, this also shows that the essence of Markdown is to strengthen the convenient syntax for HTML, and we can use it as a HTML usage.

However, not all authoring platforms support the <table></table> syntax. The author is often troubled by it. For example, some platforms will block the native HTML syntax to ensure the so-called "security" or the "consistency" of the content experience. The missing ability to draw tables often supports some custom syntax, and even worse, does not support it, which refers to the syntax expansion of Markdown.

What are the extensions of Markdown? For example: , commonMark , Github Flavored Markdown and so on.

Here is a random example, such as the standard MD format, in fact, the first line must be added with two spaces at the end to wrap, but GFM cancels this restriction. Although this is more convenient, it exposes the inconsistency of specifications between platforms, resulting in Markdown cross-platform basically must be pitted.

And do we have enough energy to learn and memorize the grammar expanded by each platform? Not to mention whether it can be remembered or not, first of all, it is a question of whether it is worth learning. Why does an online writing platform need to occupy the cost of writers’ learning and cognition, instead of finding ways to simplify the writing process? Therefore, grammar expansion seems very good, but from the perspective of writers, or from the perspective of the entire Internet platform, this non-standard approach must be unreliable. No user thinks that your platform is qualified to "teach him grammar". , unless you are WeChat, Dingding or Feishu.

The original point of view is:

1. As a writer, you don't know what syntax is available in Markdown and which isn't.
2. There are some fuzzy areas in the standard specification, lead to various entanglements when developers implement them.

The original text also mentions an example where the syntax expansion leads to an increase in the cost of understanding: the mrkdown customized by the slack platform does not support the [link](https://slack.com) method to describe links, but uses the <link|https://slack.com> syntax.

To sum up, the expansion of Markdown grammar should be a good thing, but the actual lack of standards has led to the blooming of standards, making Markdown a state where there is actually no standard, and overall there are more drawbacks.

User groups for Markdown

Markdown's positioning of itself is actually very unclear, which has also led to a lack of wanting to determine standardized syntax.

At first, Markdown was a markup language for people who were familiar with HTML, but then it turned to developers in essence for the user group, because developers thought of expanding the grammar to meet more complex usage scenarios, and the native grammar of Markdown could not adapt to more and more Complex visual display form.

Today, the main users of Markdown are developers and people interested in code. This is not to say how much developers like it, but to say that the audience of Markdown has narrowed. Today, any document editor for non-developers will not use Markdown, but WYSIWYG (what you see is what you want) mode.

The transition process is painful, but now it is a consensus that rich text editors should not use Markdown syntax, but WYSIWYG mode.

From paragraph to block, from article to application

To put it simply, Markdown is no longer suitable for the current HTML-rich ecosystem. It can easily describe the markup language of paragraphs. When encountering interactive component blocks, solutions such as MDX have to be introduced, but such solutions are only It is suitable for programmer groups and cannot be ported at all.

The form of web browsing has also developed from simple articles to integrated applications. These applications have complex layouts, styles and interactions. If you try to extend the syntax based on Markdown, you may find that it is better to use native HTML directly.

Demand for structured content

From a programming point of view, it is understood as "component reuse". The native syntax of Markdown cannot realize the reuse of content. If the content must be reused, it can only be repeated in each place, which will inevitably cause huge synchronization costs.

For example, Jekyll proposed the FrontMatter concept to create multiplexed variables:

---
food: Pizza
---

<h1>{{ page.food }}</h1>

WYSIWYG editors should not use HTML as the underlying data structure

Although browsers really use HTML as the underlying data structure, this does not mean that WYSIWYG editors can do the same, which is why browsers can only provide output from source code to UI, but not from UI editing to source code reverse input.

Because there is no one-to-one correspondence between user input and HTML, there are a lot of fuzzy areas. For example, if the current cursor is between bold and thin text, should the next input be bold or not? Bold labels are not visible from the UI. Also, if there is redundancy in HTML, in fact, the current cursor position has been wrapped by a bold tag for several layers, but because the area where the cursor is located is covered by another style tag into a non-bold mode, it may jump out when entering again. The coverage has become bold again. Is this process in line with user expectations? 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 it is structured and easy to retrieve.

The most important manifestation of structuring is that the generated HTML structure can be stable, that is, for a text that is both bold and red, it must be wrapped in a <strong style="color: red"> tag, not <strong><div style="color: red"> , that is, this mode does not put HTML is regarded as structured data, and naturally there will be no ambiguity.

The same is true for Markdown, which itself has ambiguities similar to HTML tags, and is not suitable for storage as an underlying data structure.

intensive reading

There are few articles criticizing Markdown. After reading it, I realized that Markdown has so many shortcomings. The author combines his own experience to talk about the shortcomings of Markdown.

The frustration of not supporting rich interaction

Markdown can only support simple HTML structure, but cannot describe logical blocks. Most of the Readmes on Github use pictures to implement these functions, including status cards, construction results, personal information business cards, etc. Unfortunately, the interaction ability is still too weak. I think Github should one day introduce the concept of small blocks such as Block, so that these blocks Markdown can be inserted directly into an interactive element.

Does MDX solve the pain points of Markdown?

MDX, which seems to be perfectly compatible with JSX and Markdown, was once the life-saving straw for the author, but the portability of this solution is a major pain point. The components can only be used on the website that you deploy. If you want to publish the article to another platform, it is not at all. possible.

This is only the author's perspective. From the perspective of the Markdown ecosystem, MDX is only for programmers, and it does not solve its mission of "facilitating online writing", and programmers will eventually abandon MDX and turn to development WYSIWYG The editor solves the problem.

Logic problem with Markdown to HTML conversion

Markdown is essentially a text representation structure separated from HTML. It seems that the decoupling is very elegant, but in fact it will encounter many inconsistencies.

For example, what happens when you tap multiple spaces in a row? In Markdown, it will become a reference block, so how can you display multiple spaces? No one knows, it may be possible to do this by consulting the additional syntax provided by the specific platform.

This kind of situation is generally convenient to use, but the details cannot be customized, and even the user cannot control the situation, which will greatly hurt users who have already used Markdown deeply. At this time, users will either bite the bullet and invent new syntax to solve these loopholes, or give up Markdown completely.

Insufficient structural ability

It seems that the syntax of Markdown is quite structured, but in fact the structure of Markdown is not strictly binding.

Take JSON as a comparison, for example, we can use JSON to expand the https://json-schema.org/ structure, this structure can even deduce a complete form application, the reason is that JSON can be used for each Key, lower level Definitions have structure first and content second.

Markdown, on the other hand, is just the opposite, with content first, and then structure. For example, we can write any HTML tags or any paragraphs in Markdown. These contents cannot be serialized. Even if we parse it into JSON according to the rules of browser parsing HTML, we cannot easily extract information from it.

The fundamental reason behind it is that Markdown itself is positioned as "close to the UI rendering result". In fact, a set of strict HTML syntax is required behind the UI rendering by the browser, because the UI and the syntax behind cannot be mapped one by one, a stable one. The rendering logic can only be deduced from the source code to the rendering, and cannot be deduced from the source code from the rendering. The positioning of Markdown itself is close to the rendering result, so the lack of structural ability is a natural problem.

Summarize

I remember that in the early internal trial of Yuque, Markdown was still used in the editing state, but the editing entry of Markdown was soon dropped. This incident also caused the dissatisfaction of many developers, and there were even some Markdown editing plug-ins. It was developed and was once very popular. But gradually we are all used to editing in WYSIWYG. The only impression of Markdown is the shortcut keys. For example, typing a space after ### can generate h3 title paragraph, and the Yuque editor is also in the rich interactive component block. Going further and further, if the technology was locked by Markdown back then, it would be impossible to have such an advanced editing experience today.

So technical foresight is really important. Markdown is loved by all programmers, but we should see its limitations in the current Internet development stage in advance and design a set of structured data to replace the Markdown structure. Not everyone can think of it, we need to Looking at technology from a dynamic perspective, we must also let go of the prejudice of technical people and give way to product positioning.

The discussion address is: Intensive Reading "Thinking about Markdown" Issue #397 dt-fe/weekly

If you want to join the discussion, please click here , there are new topics every week, released on weekends or Mondays. Front-end intensive reading - help you filter reliable content.

Pay attention to front-end intensive reading WeChat public number

<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">

Copyright notice: Free to reprint - non-commercial - non-derivative - keep attribution ( Creative Commons 3.0 License )