Markdown in 2016
Markdown、あなたのすぐとなりに潜む問題
昨日は toc 拡張の話ついでに、現在の Sphinx と markdown を取り巻く環境について愚痴ったわけですが、Markdown 業界は 2016年のこの時期になっても、いまだに共通的な仕様が決まっていません。
2004年、John Gruber によって生み出された Markdown は、12歳を迎えた現在、さまざまな markdown 処理系を持っています。
そして、不幸にも実装によって markdown の処理はそれぞれ異なってしまっています。
これは Markdown の仕様が曖昧であることと、それぞれの処理系で文法の拡張を行っていることから来ています。
Markdown 処理系による違い
Markdown の仕様が曖昧であることは、さまざまな混乱を生み出しました。
babelmark2 が示すように、同じマークアップであっても処理系によって出力結果が変わってしまうということが起きています。
これに対して、2014年10月に CommonMark プロジェクトが立ち上がります。
CommonMark プロジェクトは Markdown のあいまいな仕様を整理しなおし、マークアップごとにどういう風にレンダリングされるべきか、また解釈の優先順位はどうなるべきかなど、詳細な仕様を定めることをゴールとしたプロジェクトです。
昨日触れた recommonmark も、この CommonMark に準拠した実装のひとつです。
(より正確には、CommonMark 仕様に準拠した python 実装である CommonMark パッケージを Sphinx から利用できるようにラッピングしたものです)
文法の拡張と方言化
もうひとつの Markdown の問題は文法の違いです。
オリジナルの Markdown には必要最低限のマークアップしか定義されておらず、それ単体では表すら書くことができません。
オリジナルの Markdown では表や脚注、定義リストなど、幾つかの要素を持っていないため、
ドキュメントの内容によっては表現できないものがあります。
Markdown には HTML を含めることができるので、HTML をごりごり書くことで回避はできますが、あまりスマートではないですよね。
こうした課題を解決するために、おおくの Markdown 処理系で文法を拡張しました。
有名なのものとしては、多くの人が使っている GFM こと Github Flavored Markdown や
PHP Markdown Extra などが挙げられます。
他にも拡張したものは数多く存在します(参考： Wikipedia Markdown#利用例と方言)
こうして、Markdown には "基本的な文法” は同じだが、ちょっとしたおまけの文法がある Markdown の方言が雨後の筍のように大量に存在するのです。これが現代のバベル、Markdown なのです*1。
2016年に起きたこと
2016年は Markdown の大きな節目になる…はずでした。
CommonMark 1.0 がリリース…されなかった
commonmark.org には、以前からこんな記述があります。
When is the spec final?
The current version of the CommonMark spec is complete, and quite robust after a year of public feedback … but not quite final.
With your help, we plan to announce a finalized 1.0 spec and test suite in early 2016.
しかし、あと2日弱で 2016年が終わろうとしている今日現在でも、1.0 はリリースされていません。
11月18日には 0.27 がリリースされていますが、いつごろ 1.0 はリリースされるのでしょうか。
CommonMark が定まることで、処理系ごとにマークアップが異なっていた問題は徐々に収束していくものと思われます。
もちろん、これから各処理系を手直しして CommonMark に合わせていく作業は残っていますが、
Markdown の標準化に向けては大きな一歩になるはずです。
(まだ 1.0 とはいえ、かなり形になってきているものなので、各ライブラリでは対応が進んでいるとなお良いのですが…)
Markdown が RFC に登録された。media type として。
以前から Markdown を RFC に登録しようという動きはあったのですが、ついにそれが実を結びました。
RFC7763 The text/markdown Media Type と RFC7764 Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations がそれです。
これまで説明してきたとおり、処理系によって解釈がまちまちだったり、さまざまな方言が存在する状況で、Markdown はどのように標準化されたのでしょうか?
ふたつの RFC では、Markdown に関するパラメータが次のように定義されました。
- IANA で markdown の方言を Markdown variants として登録管理することになった
- media type には text/markdown を使うことになった
- このふたつを組み合わせて Content-Type ヘッダで text/markdown; variant=Original と指定できる
つまり、RFC は Markdown の “文法” を標準化したのではなく、
1. Markdown の文法が分断されていることを追認した上で、
2. どの文法を使っているのか(使うのか)を variant として media type で示すことができる
という標準化だったのです。
わかりますね? IETF でもばらばらになった方言はどうにもならなかったのです。
RFC7763 には次のような説明があります。
Markdown variations (some might say "innovations") are designed to
be broadly compatible with humans ("humane"), but not necessarily
with each other. Therefore, syntax in one Markdown derivative may
be ignored or treated differently in another derivative.
意訳：
まとめ
- Markdown の標準化はちょっとずつ進んでるみたい
- でも、まだ方言問題は解決しそうにない
- もし処理系を作る場合は方言を増やさないようにしましょう
おまけ
CommonMark にテーブル記法を足そうとか、recommonmark (CommonMark 処理系)に様々な便利文法を足そう、みたいな提案やイシューが並んでいるのを見て、まだしばらくは方言問題は解決しないんだろうなあ、と感じました。
