🧭

Markdownへの期待──非破壊的進化の限界と、その先にある設計

に公開2件
Markdown
提言
非破壊的進化
idea

序章：Markdownの現在地

Markdownは、自由に生まれた記法だ。

厳密な仕様は最小限。
実装や解釈は各所に委ねられ、「人が読めること」が何よりも優先された。

この自由さが、Markdownを急速に普及させた原動力だったことは疑いない。

README、設計メモ、技術記事、ブログ。
Markdownは、特別な記法ではなく、日常的に使われる書き言葉になった。

その普及において、GitHubが果たした役割は大きい。
採用の順序や影響関係を正確に分類することは難しいが、
Markdownを事実上の共通言語に押し上げた存在であることは間違いない。

一方で、その自由は別の課題も生んだ。
その結果、Markdownは多くの場所で使われるようになったが、
同時に解釈の分岐も増えていった。
Zenn、Qiita、Obsidianなど、
Markdownを採用するサービス/ソフトウェアは数多く存在し、
それぞれが独自の拡張や解釈を持っている。

  • 方言の乱立
  • 拡張記法の非互換
  • 環境によって表示や意味が変わるMarkdown

自由であるがゆえに、
ポータビリティが犠牲になった。

Markdownは十分に普及し、用途も広がった。
章立ての文章だけでなく、設計書、ブログ、Webデザインにも使われている。

設計書では表や図が求められ、
ブログやWebデザインでは、複数カラムなどの視覚的整理も求められる。

HTMLやCSSが進化し、表現力を高めてきた一方で、
Markdownの表現力は初期のままに留まっている。

これは失敗ではない。
だが、停滞と呼ぶには十分な状況だ。

Markdownは没落していない。
利用者も、実装も、エコシステムも十分に存在する。

いま必要なのは、新たな推力ではない。
勢いを殺さず、方向を誤らないための制御だ。

ただのプレーンテキストに、
少しの手間をかけるだけで修飾できる。
目立たせ、分かりやすく、
意図を正確に伝えることができる。

Markdownは、
そんな魔法のような記法だ。

その魔法を失わずに、
次の段階へ進むことはできないのか。
本稿では、その可能性を整理する。

第1章：Markdownが守ってきた原則

Markdownの最大の価値は、
解釈されなくても内容を読み取れることにある。

  • 古いエンジンで一部の拡張が無視されても
  • プレーンテキストとして内容が伝わる
  • 意味はテキスト側に残る

これが崩れる拡張は、Markdownではない。

多くの場合、文章は
書きながら装飾されるか、
装飾を意識しながら書かれる。

どちらを重視するかは書き手のスタイルの違いに過ぎない。
しかし、より重要なのは別の点にある。

まずプレーンテキストとして全文が存在し、
その上に装飾が重ねられるケースが確かに存在する、ということだ。

だからこそ、
装飾のために文書の構造そのものを
大きく作り替えなければならない表現は避けるべきだと思っている。

装飾が失われても、あるいは解釈されなくても、
内容そのものは読み取れる。

この性質こそが、
Markdown が Markdown であり続ける理由であり、
拡張を考える上で守られるべき前提だ。

第2章：自由が生んだ歪み

Markdownは成長の過程で、次の制約を抱えた。

同じ意味に複数の記号が存在する点は、その一例だ。
``` / ~~~ は、いずれもコードブロックを表す記法だ。

また、次の箇条書きは見た目上は同じ意味を持つ。

  • item
  • item
  • item

実際には、次のように異なる記号で書かれている。

- item
+ item
* item

それ以外にも、次のような課題がある。

  • 記号重複による記号資源の枯渇
  • 独自拡張による方言の乱立
  • 表現力不足をHTMLで補うと可読性が落ちる

主要なASCII記号の多くには、すでに役割が割り当てられている。
新たな装飾記法を追加しようとすると、既存記法との衝突を避けるのが難しい。

その結果、独自拡張はインラインではなく、
ブロック型の装飾に偏る傾向がある。

これは、記号資源の枯渇を示す一つの兆候だと言える。

これらは設計ミスではなく、
初期の利便性を優先した結果として現れた制約だ。

Markdownは自由であったがゆえに、
拡張の余地そのものが見えにくくなっている。

第3章：なぜ拡張を慎重に扱うのか

Markdownとしては、自由な拡張も可能だ。
しかし、過去の反省から、あえてそれを選ばない。

  • 自由な拡張は分断を生んだ
  • 同じ失敗は繰り返したくない

だから必要なのは、新仕様の断定ではなく、
筋の通った拡張の方向性を示すこと。

拡張を軽率に扱うことの問題は、
失敗したときに元へ戻れない点にある。

記法として広まってしまった拡張は、
たとえ誤りに気づいたとしても、
互換性のために抱え続けるしかなくなる。

その結果、
「便利だが扱いづらいMarkdown」が積み重なり、
文書の可読性と移植性が静かに損なわれていく。

第4章：壊さない拡張の条件

拡張は、次の条件を満たす限りにおいてのみ、肯定できる。

  • 未対応環境でも読める
  • 解釈に失敗しても意味が変わらない
  • 意味を追加せず、表示を最適化するだけ
  • 失敗時は「縦に並ぶ」など安全に崩れる

これらの条件は、新たに持ち込まれた思想ではない。

Markdownの初期設計においても、
プレーンテキストとして読めることは最優先事項だった。
装飾が解釈されなくとも、内容を読み取れることが前提とされている。

本稿で述べている「壊さない拡張」は、
その原初思想を、現代の利用状況に合わせて整理したものに過ぎない。

マルチカラムの流し込みが許されるのは、
短くしたいだけで、意味は変わらないからだ。

ここで挙げる条件は、
Markdownにすべての表現力を求めるものではない。

Markdownの責務は、
構造と意図をテキストとして残すことにある。
表示の最適化や装飾の詳細は、
レンダラやツール側に委ねられるべきだ。

この責務の分離が守られる限り、
拡張はMarkdownを壊さない。

第5章：バージョンという整理の仕方

方言の乱立は、否定されるべきものではない。
それはニーズの表れであり、拡散フェーズにおいては必要な現象だ。

しかし多くの技術は、
拡散と収束を繰り返しながら進化してきた。
SQLやHTMLも、独自拡張を取り込みつつ、
標準化によって次の段階へ進んできた。

Markdownもまた、
拡散のフェーズを十分に経験した技術だ。
いま求められているのは、
次のフェーズへ進むための整理だと考えている。

本稿が目指すのは、
Markdownのすべてを統一することではない。

主流の一部でいい。
多くの人が迷わず選べる書き方が、
自然と共有されていけばいい。

それが積み重なれば、
結果として方言は減り、
ポータビリティは回復していく。

統合とは、
完成形を宣言することではなく、
選ばれる方向を示し続けることだ。

  • v1：現状のMarkdown（事実として受け止める）

  • v2：互換性を最大限維持しつつ整理する

    • Front Matter など既存エコシステムを活用

  • v3：破壊的整理を含む刷新（最初から破壊を宣言）

破壊的変更は悪ではない。
宣言されていない破壊が悪。

これまでは、ロケットの第1段階として大きな推力が必要だった。
しかしこれからの第2段階では、
もはや大推力はいらない。

必要なのは、間違いのない方向性だ。

第6章：なぜ、これらの改善が欲しいのか

本章では、Markdownに対する具体的な改善案を挙げる。
ただし、述べたいのは「どう実装するか」ではない。

主張したいのは、
なぜその表現が欲しいのか、
そして どのように書けると嬉しいのか という要求だ。

Markdownは、設計書や技術文書、レビュー資料など、
当初想定されていなかった用途でも使われ続けている。
選ばれている以上、
現実の要求を「用途外」として切り捨てることはできない。

ここで挙げる改善案は、
Markdownにすべての表現力を求めるものではない。
主流の一部でいい。
迷わず選べる書き方が共有されていけばいい。

それが結果として方言を減らし、
Markdownを次の段階へ進めると考えている。

6.1 表形式の拡張が欲しい理由

設計書を書くとき、実際には次のような表を書きたい場面が多い。

<table>
<tr>
<th rowspan="2">機能</th>
<th colspan="2">仕様</th>
</tr>
<tr>
<th>条件</th>
<th>動作</th>
</tr>
<tr>
<td>ログ出力</td>
<td>
<ul>
<li>INFO</li>
<li>ERROR</li>
</ul>
</td>
<td>ファイルに出力</td>
</tr>
</table>

HTMLを使えば、このような表は問題なく書ける。
Markdown としての可読性は落ち、差分も追いづらくなる。
設計書やレビュー用途では、これは大きな負担だ。

また、設計書では
「この表のここを見てほしい」
と参照したい場面が多い。

図表番号があれば、
表や図を明確に指し示すことができ、
レビューや議論が格段にしやすくなる。

情報を整理して見せるためには、
次のような柔軟性が欲しい。

  • 見出しセルを縦・横にまとめる
  • セルの中に短い文章や箇条書きを自然に書く
  • 内容量に応じて列幅をある程度揃える

これらができれば、設計書としての可読性は大きく向上する。

未対応の環境では、通常の表として読めればそれでいい。
多少表示が崩れても、意味が失われなければ問題はない。

表形式の拡張は、これからの Markdown への期待の表れだ。

ここで提案したいのは、
従来の 「1セル1行」という書き方に加えて、
「1セルの中に複数行」を書ける表記を許容することで、
表が持てる表現の幅を広げたい。

セル内に短い文章や箇条書きを自然に書けるようになれば、
情報を無理に分割したり、説明文に逃げたりする必要はなくなる。

このような表現が可能になると、対比構造もより素直に表現できる。
左右（あるいは上下）に意味的な対応関係を持つ要素を並べることで、
比較・対照・Before / After といった関係が明確になる。

これらはいずれも、
Markdown に新しい意味論を持ち込むものではない。
既に存在する情報を、構造として整理し、読みやすく示すための工夫に過ぎない。

6.2 マルチカラムが欲しい理由

6.2.1 マルチカラムの可読性

Markdownで短い箇条書きを並べていくと、
内容は単純なのに、縦に間延びしてしまうことがある。
特に一覧性が求められる場面では、これは地味に効いてくる。

たとえば、次のような箇条書きだ。

  • Alpha
  • Beta
  • Gamma
  • Delta
  • Epsilon
  • Zeta
  • Eta
  • Theta
  • Iota
  • Kappa

項目そのものの意味は明確だが、
一覧としては縦に長く、全体を把握しづらい。
このような場合、2列や3列に折りたたむだけで、
見通しは大きく改善する。

ここで求めているのは、新しい意味ではない。
項目同士の関係や順序を変えたいわけでもない。
配置を調整して、読みやすくしたいだけだ。

そのため、未対応の環境では、
従来どおり縦に並んで表示されればそれでよい。
列が崩れても、意味が変わらなければ問題はない。

もしマルチカラムに意味を持たせたいのであれば、
それは表形式を使うべき場面だ。

マルチカラムの要求は、
Markdownを派手にしたいからではない。
構造をテキストとして保ったまま、
可読性と一覧性を高めたいという期待の表れである。

意味や構造を変えずに、読みやすさと一覧性の改善のために
たとえば、このような用途でマルチカラムを使いたい。

  • 短い箇条書きが縦に長くなりすぎる場合
  • 用語一覧・チェックリスト・軽い列挙
  • エッセイや読み物で、視線移動を減らしたい場合

「ここからここまでを折りたたみたい」
という、範囲指定によるレイアウトの調整だ。
例えばこんな感じで2列指定とか。

:::columns:2
* Alpha
* Beta
* Gamma
* Delta
* Epsilon
* Zeta
* Eta
* Theta
* Iota
* Kappa
:::

未対応の環境では縦に並べばよい。
表示が崩れても、意味が変わらなければ問題はない。

段組みそのものは、有効な表現になり得るが、制御が難しい。

  • 何行で折り返すか
  • 縦方向のバランス
  • 3列2段などの組み合わせ

こうした判断は表示側に委ねられる部分が大きく、
軽量記法として扱うには慎重さが必要になる。

長文においては意図通りにはならないだろう。

そのため本提言では、
まず 箇条書きや短文を対象としたマルチカラムに限定する。
ここで求めているのは、段組みそのものを完成させることではなく、
段組みを構成できる手段を得ることだ。
長文の段組みについては、将来検討すべき領域と位置づける。

6.2.2 カラーによる視線誘導

文章の中で、
「ここが重要だ」と伝えたい場面は多い。

現状の Markdown では、
強調は太字や斜体に限られることが多く、
情報の性質までは伝えにくい。

色を使った強調は、
新しい意味を加えるものではない。
既に書かれている内容の中から、
どこに注目して読んでほしいかを示す手段だ。

安直だが、例えばこんな風に。

<red>赤い車</red>
<blue>青い星</blue>

重要なのは、
色そのものに意味を持たせないことだ。

色が失われても、
文章だけで意味が成立すること。
対応関係や強調点は、
文脈から読み取れること。

この条件が守られる限り、
カラーは Markdown の可読性を損なわない。

なお、色による強調はアクセシビリティの観点から多用すべきではない。

万人が同じ色を同じ意味で認識できるとは限らず、
表示環境や支援技術によっては色そのものが失われる場合もある。

このため、色は意味を担わせるのではなく、
表示上の補助として扱うのが望ましい。

6.2.3 セクションセパレータによる読みやすさ

長い章や節の中では、
見出しを増やすほどではないが、
話題が切り替わる場面がある。

このようなとき、
軽い区切りを入れられるだけで、
読み手は一息つくことができる。

セクションセパレータは、
文書の構造を変えるものではない。
見出しを増やすわけでも、
意味を分割するわけでもない。

あくまで、
読むリズムを整えるための装飾だ。

たとえば、区切りを表すために、

  • -.- のような軽い記号列を、薄い区切りとして描画する
  • -*- のような記号列を、やや強めの区切りとして描画する

といった表現も考えられる。

未対応の環境では、
単なる文字列としてそのまま表示されてもよい。
それでも文意が変わることはない。

6.2.4 まとめ

本節で挙げたマルチカラム、カラー、セクションセパレータは、
いずれも Markdown に新しい意味論を持ち込むものではない。

構造や意味はテキストに残したまま、
表示や視線誘導だけを最適化する。

失敗しても安全に崩れ、
未対応環境でも読める。

この条件が守られる限り、
これらの拡張は Markdown を壊さない。

6.3 方言として存在する補助表現を、どう整理するか

いずれも表記は異なるが、
「ここは注意して読んでほしい」という意図は共通している。

> [!warning]
> 注意事項です。

:::message alert
注意事項です。
:::

⚠ 注意事項

各サービスやレンダラが独自に導入してきた
note / warning / tip / コラム / 折り畳みといった表現は、
現時点では Markdown の標準仕様ではなく、Markdown の方言である。

しかし、ほぼ同じ用途の表現が
複数の環境で繰り返し実装されてきた事実は、
それが単なる装飾ではなく、
実際の利用に根ざした要求であることを示している。

この提言は、
新しい記法を定義することではない。

すでに存在している方言的な機能を、
用途の観点から整理し、
指定方法を統合していくことの意義を示すこと

にある。

6.3.1 問題は「方言の存在」ではない

方言が存在すること自体は、問題ではない。
むしろそれは、現実の利用に即した進化の結果である。

そのため各サービスは、

  • note / warning / tip などの補助ブロック
  • callout やコラム表現
  • details / summary による折り畳み

といった形で、
それぞれ独自に解決してきた。

問題となるのは、次の点だ。

  • 同じ用途なのに、指定方法や名称が異なる
  • 何のための表現なのかが明示されていない
  • どこまで使ってよいかの線引きが曖昧

その結果、

  • 文書の移植性が下がる
  • 書き手ごとに使い方がばらつく
  • 読み手が「どう読めばよいか」迷う

という状況が生まれている。

6.3.2 用途ベースで指定方法を統合する

ここで目指すのは、
表現方法を統一することではない。

統一したいのは、指定方法だけである。

現在の方言的表現は、
大きく次の用途に整理できる。

  • 読む姿勢を示す（注意・補足・ヒント）
  • 本文から外れる位置づけを示す（コラム）
  • 情報量を制御する（折り畳み）

指定の記法や見た目は異なっていても、
意図は驚くほど共通している。

用途を揃えることで、

  • 書き手は
    「何のために使っているか」を意識できる
  • 読み手は
    「どう読めばよい情報か」を直感的に判断できる
  • 実装側は
    対応する用途を明示できる

ようになる。

アイコンや色、レイアウトといった表現は、
実装やデザインに強く依存する。

そのため、表現としての方言は今後も残る。

本提言は、それを統一しようとするものではない。

  • 既存の表現は踏襲してよい
  • レンダラごとの個性も尊重される
  • 不足が見つかれば、用途として追加される

重要なのは、同じ指定が、同じ意図として解釈されることである。

6.3.3 指定方法の変更とバージョン

用途ベースで整理を進めていく過程では、
指定方法そのものが見直される可能性がある。

ここで問題となるのは、
変更そのものではなく、宣言されていない変更である。

第5章で述べたとおり、
指定方法が変わる場合には、

  • 文書側でバージョンを明示する
  • バージョンに応じて解釈を切り替える

ことで、互換性を保ったまま整理を進めることができる。

これは、方言を排除するための仕組みではない。

方言を、バージョンという単位で
段階的に収束させていくための仕組みである。

6.3.4 まとめ

6.3 の立場は明確だ。

  • 扱っている表現は、現時点では方言である
  • しかし、実需要に基づいている
  • 統一するのは指定方法（意図）だけ
  • 表現方法は縛らない
  • 変更はバージョン指定によって切り替える

方言を否定するのではなく、
整理し、使い続けられる形にする。

それが、この節の結論である。

6.4 用語参照と理解コストの削減

IT 系の文書では、略語や専門用語が当然のように使われる。
その理解は、知識と慣習に頼っている。
初見では、どの意味で使っているかが、すぐ理解できないことだ。

同じ略語が、同一文書・同一会話の中で、
異なる意味を取ることすら珍しくない。

6.4.1 略語と用語が生む齟齬

たとえば QA という略語は、

  • Question & Answer
  • Quality Assurance
  • Quality Analyst

など、複数の意味を持つ。

どれが正しいかではなく、
この文書ではどれを指しているのかが重要だ。

定義されない略語は、読み手に推測を強いる。

説明のない略語は、読み手に対して失礼である。
「これくらい知っていて当たり前だ」と
書き手が無言の前提を押し付けているように見えてしまう。

特に問題なのは、
同じ略語が 同一文書・同一会話の中で異なる意味を取りうる 点にある。
このとき、文脈による補完は人によって異なり、
齟齬は静かに積み重なっていく。

6.4.2 囲うだけで「用語」を示す

書き手が本当にやりたいことは、
リンク先を細かく指定することではない。

これは用語である
と示したいだけである。

略語でも、漢字でも、
特定の記号で囲うことで、

  • 用語集に存在する語であることを示す
  • レンダラが自動的に定義を解決する

という形が取れれば、
書き手の負担は大きく下がる。

6.4.3 ToolTip によるインライン参照

用語の確認のために、

  • ページ末尾へ飛ぶ
  • 別ページへ移動する

といった操作は、
読みの流れを分断する。

用語集への参照は、
その場で、軽く確認できることが望ましい。

ToolTip 形式であれば、

  • 知っている人はそのまま読める
  • 初見の人だけ補足を見ることができる

未対応環境では、
通常の文字列やリンクとして読めればよい。

6.4.4 まとめ

ここで提案しているのは、

  • 新しい意味の追加ではない
  • Markdown 文法の拡張でもない

閲覧支援としての最適化である。

用語集は既に存在する。
必要なのは、そこへ辿り着くコストを下げることだ。

略語や専門用語は、専門性の証明ではない。

書き手と読み手の認識が一致してこそ、
略語は成立する。

6.4 が目指すのは、
「知っている前提」を文書側が引き受けることにある。

6.5 メタ情報と参照性の向上

本節で扱うのは、
Markdown の表現力を拡張することではない。

文書を 一度書いて終わりにしない ために、
どのような補助情報と構造が必要かを整理する。

ここで言うメタ情報とは、
本文の意味を増やすものではなく、

  • 文書をどう扱うか
  • どこを参照しているか
  • どう辿れるか

といった、読む前提・使う前提を支える情報を指す。

6.5.1 文書メタ情報と MDV 宣言

Markdown 文書には、
本文とは別に管理および解釈のための情報が必要となる。

このための仕組みとして、
YAML による Front Matter はすでに広く使われており、
事実上の標準となっている。

本提言では、これを新たに仕様化するのではなく、

既存の YAML Front Matter を、
文書メタ情報の標準的な置き場として認知する

ことを宣言する。

ここには、従来どおり、

  • title
  • 文書のバージョン
  • 著者
  • 状態（draft / review / final など）

といった情報を記述できる。

加えて、第5章で述べた
MDV（Markdown Version） を
ここで明示的に宣言するものとする。

mdv: 2

文書のバージョンと MDV は役割が異なる。

  • 文書のバージョン
    → 文書そのものの管理情報
  • MDV
    → 文書の解釈ルールの指定

両者を分離して宣言することで、
内容の更新と解釈ルールの変更を
独立して扱うことができる。

これは、HTML における文書型宣言と同じ立場である。

6.5.2 セクション参照

文書内で説明を参照する行為は、
技術文書において避けられない。

  • 「後述する○○を参照」
  • 「△△節で説明した内容」

これを安定して行うためには、
文書内の位置を指し示す仕組みが必要となる。

セクション参照とは、
文書内の特定位置に対して
参照可能な名前（ラベル）を与え、
それを用いて参照する仕組みである。

6.5.3 参照される側のラベル定義

セクション参照を成立させるには、参照する側の記法だけでなく、
参照される側にラベルが定義されていることが前提となる。

多くの Markdown 実装では、
見出しから自動的に ID が生成される。

これは便利ではあるが、

  • 見出し文言の変更
  • 章構成の修正
  • 節の入れ替え

といった編集に弱く、
長期的な参照には向かない。

重要なのは、
見出しと参照名を分離することである。

  • 見出しは、読むための構造
  • ラベルは、参照するための名前

参照を前提とする箇所には、
見出しとは独立した、
意味に基づくラベルを
書き手が明示的に指定できることが望ましい。

6.5.4 自動生成と手動指定の役割分担

自動生成されたラベルは、
省力化のための仕組みとして有用である。

しかし、それは
参照の安定性を保証するものではない。

本提言における立場は明確である。

  • 自動生成は、楽をするための補助
  • 手動指定は、参照に責任を持つための指定

書き手が意図して参照される箇所には、
手動でラベルを指定できることが重要である。

自動生成と手動指定は対立するものではなく、
役割を分けて併用されるべき仕組みである。

6.5.5 本節のまとめ

Markdown の記述力を増やすものではない。

文書を「書く」ためではなく、
「使い続ける」ための層である。

  • 文書全体にはメタ情報を与える
  • 文書内部には安定した参照点を用意する

これにより、

  • 構成変更に強く
  • 再読や参照に耐え
  • 読み手に前提を押し付けない

文書が成立する。

メタ情報と参照性の整理は、
Markdown を複雑にするためではなく、
Markdown を長く使える形に保つための設計である。

6.6 本章における v2 / v3 の位置づけ

本章で述べた提案は、すべて同じ影響度を持つものではない。
第5章で示した MDV の考え方に照らすと、
おおよそ次のように整理できる。

MDV2（非破壊的進化）に相当するもの

  • 表形式の拡張(6.1)
    • 1列1行形式（既存構文の解釈拡張）
  • 表示最適化に関する提案（6.2）
    • マルチカラム表示
    • セクションセパレータ
    • 色やアイコンによる視認性向上（意味を持たせないもの）
  • 用語参照や ToolTip による理解支援（6.4）
  • YAML Front Matter の整理と認知（6.5）

これらは、既存の Markdown 文書を破壊せず、
未対応環境でも文意が損なわれない形で導入できる。

MDV3（破壊的進化）に相当するもの

  • 表形式の拡張(6.1)
    • 1列複数行形式（新しい構造解釈）
  • 方言的補助表現の指定方法の統合（6.3）
  • 指定方法と解釈ルールを用途ベースで再定義する整理

これらは、指定方法や解釈ルールの変更を伴うため、
文書側で MDV を明示した場合にのみ有効とすべき整理である。

ここでの整理は、実装や対応を要求するものではなく、
影響範囲を把握するための便宜的な位置づけである。

6章まとめ

本章で挙げた改善案は、
Markdown を別の言語に作り替えたいわけではない。

書き手が望む表現力と、
読み手の理解コストの低減を、
両立させるための提言である。

その多くは、既存の文書を壊さずに導入できる
非破壊的な改善（v2 相当）として整理できる。
一方で、方言の整理や指定方法の統合といった一部には、
破壊的な見直し（v3 相当）が必要となる領域も含まれる。

すべてを統一する必要はない。
主流の一部でいい。

だが、いまの Markdown は
拡散だけが続き、収束の機会を欠いている。

誰かが決めるのではなく、
誰かが整理を始める。
その一歩が、そろそろ必要なのではないだろうか。

結語：この提言の立場

この提言は、
特定の実装や対応を一律に宣言するものではないし、
Markdown の仕様を定めるものではない。

Markdown の弱点は、
記法を捨てなくても、
拡張の方向性を整理することで補える。

本稿は、その可能性を示すにとどまる。

使われ続ける技術は、用途が広がり、要求も増えていく。
放置すれば、現実との乖離が静かに広がるだけだ。
だからこそ、壊さずに進化できる道筋を示すことが求められている。

しかし同時に、非破壊的進化だけでは、
もはや現実の要求に追いつけない局面に来ている。
たとえば、表形式の拡張や補助ブロックの整理、用語参照や表示支援といった、
すでに各所で実装され、使われている要求に応えるには、
破壊的進化を安全に扱う仕組みが必要だ。

Markdown は長らく、独自進化を容認することで発展してきた。
しかしその自由さは、次の段階へ進むための障壁にもなりつつある。
いまここで、バージョンというスイッチを用いて破壊的進化を安全に受け入れる構造を整え、
統合へ向けた一歩を踏み出す必要がある。

Markdown の使われ方は、圧倒的な利用規模を持つ実装の選択によって形づくられてきた。
だからこそ、その力を行使し、進むべき方向を示せる立場にある存在が、
次のフェーズへの道筋を開く責務を担っている。

その先陣を切る存在になってくれることを、期待したい。

Discussion

kemiikemii

自分用メモ

マークダウン記法は、文字を表示したときにそのまま読むことができることを優先する。

これは理解できた。
<red>

これはまだよく分かっていない

<marker > などであれば、マークしたいんだなということがわかる。

tailwind的な思想なのか。

plusone｜開発技法ノートplusone｜開発技法ノート

コメントありがとうございます。

<red> は、単に「赤くしたい」という意味で使っています。
本来は Markdown の性格上、「warning」や「note」のように意味を持った装飾が望ましいのだろうと思っています。

ただ、実装やレンダラ依存の問題もあり、意図した色や表現にならない可能性もあります。
そのため、ここではまず「書き手が色を指定できる」という選択肢があってもよいのでは、と考えています。

仕様を決めているわけではなく、「こんなことができたらいいな」という提案レベルの話なので、
もし他にも良いアイデアがあれば、ぜひ教えてください。