これは「Markdown Advent Caleandar 2020」の5日目の記事です。
某キータの某質問と某回答
先日、Qiitaの質問機能において次のような質問（意見交換）が投稿されました。
質問は以下の図のような「箇条書きを内部に含む段落」に関するものでした。
図1：箇条書きを内部に含む段落
投稿者の問題意識は「このような段落の構成は日本語の文書として正当か否か」というところにあり、その考察の際にHTMLやMarkdownとの対比を行っています。
この質問について、私は以下の趣旨で回答を投稿しました。（詳細については実際の回答を参照してください。）
- 日本語の文書構成の慣習では「箇条書きを含む段落」は許容されていると思われる。
※これは「自分の意見」です。 - HTML5では「文章構成上の段落1」「HTMLの段落(paragraph)」「p要素」は別個のものとして扱われている。
- 2の扱いのため、「箇条書きを含む段落」をHTML5で表すことは可能である。
※2と3は「HTML5の規格書の記述2を根拠とした事実の主張」です。
実は、この回答の続きの話として「Markdownに関する話」を書こうとも考えていたのですが、元の投稿者の問題意識から大きく外れてしまうことを危惧して割愛しました。その「Markdownに関する話」を「Markdown Advent Calendar」の記事として投稿します。
※以下では、「HTMLやMarkdownの定める段落」と明確に区別するため、「文章構成上の段落」のことを「段落」のように下線付で表記することにします。
※この記事では、Markdownの数ある方言の中で特に「Gruberによる“元祖Markdown”」と「CommonMark」を考察対象とします。この2つに由来する方言で大きな意味論上の変更を加えていないものであれば、同じ議論が成立するでしょう。
「箇条書きを含む段落」はMarkdownできるか
ます最初に、「箇条書きを含む段落」をMarkdownで表すことが可能であるかを考察します。
HTMLできるならMarkdownできるはず
例の「回答」で述べた通り、図1の文章は以下のようなHTML5のコードで表せます。
<p>これは</p>
<ul>
<li>A</li>
<li>B</li>
<li>C</li>
</ul>
<p>の3つの利点を持ちます。</p>
この例1のHTML5の文書をMarkdownに書き直せ、と言われると、多くの人は次のコードを思い浮かべるでしょう。
これは
- A
- B
- C
の3つの利点を持ちます。
この例2のコードは本当に「図1の文章を表している」と見なしていいでしょうか？
この疑問に対する答えを出すには「Markdownにおいて『段落(paragraph)』とは何なのか」について精査する必要がありそうです。といっても、元祖MarkdownにしてもCommonMarkにしても「段落とは何なのか」についての明示的な規定はありません。ただし、元祖Markdownは「HTMLの記述の代用」として考案されたものであり、またCommonMarkの規格は「文書構造を示す手段としてHTMLコードを用いる」という方針（1.3節）をとっています。これを考慮すると、「Markdownの『段落』の意味はHTMLのそれを引き継ぐ」と見なすのが妥当でしょう。つまり、「例1のHTMLコードと例2のMarkdownコードは同じ構造を表している」と見なすことができて、かつ「例1のHTMLは図1の文章を表している」のであれば、「例2のMarkdownのコードは図1の文章を表している」も成立するはずです。
イチャモンを入れてみる
ただしこの議論には穴があります。元祖Markdownが造られたのは2004年であり、このときにはまだHTML4が通用していました。となると、元祖MarkdownはHTML4の意味論を持っているとも考えられます。このことは、**...**の記法（これはstrong要素に対応します）のことを「重要（important）」ではなく「強い強調（strong emphasis）」と呼んでいることからも裏付けられます。
一方CommonMarkはどうかというと、やはり**...**を「強い強調」と呼んでいる（6.4節）ので、HTML4が踏襲されているように見えます。
例の回答で述べた通り、HTML5の段落の定義はHTML5になって初めて定められたものであり、実際、HTML4の時代には「箇条書きを含む段落」が表現できるか否かが不明瞭だったのです。となると、HTML5の記述を根拠とした議論は不適切であるという批判はありえるでしょう。（とはいえ、私見としては、今の時代にHTMLコードをわざわざ「規定が不明確なHTML4の意味論」で考える必然性は乏しいと思いますが。）
Gruberかく語りき
「箇条書きを含む段落」をMarkdownで表せるという議論を補強するために、改めてGruberによる元祖Markdownの規定を調べてみます。
よく読むと、この規定の文書自体が「コードブロックを含む段落」を含んでいます。
Ampersands in particular are bedeviling for web writers. If you want to write about ‘AT&T’, you need to write ‘
AT&T’. You even need to escape ampersands within URLs. Thus, if you want to link to:http://images.google.com/images?num=30&q=larry+birdyou need to encode the URL as:
http://images.google.com/images?num=30&q=larry+birdin your anchor tag href attribute. Needless to say, this is easy to forget, and is probably the single most common source of HTML validation errors in otherwise well-marked-up web sites.
コードブロックは箇条書きと同様に「ブロック要素」の一つであることを考えると、「箇条書きを含む段落」の問題は「コードブロックを含む段落」の問題と同じものといえます。
さらに注目すべき点として、この文書の冒頭には「この文章自体がMarkdownで書かれている」と明記されています。
NOTE: This document is itself written using Markdown; you can see the source for it by adding ‘.text’ to the URL.
このことから、Gruberは「元祖Markdownは『コードブロックを含む段落』を表すことができる」と考えていることが推定できます。実際に当該の文書のMarkdownソースを見てみましょう。
Ampersands in particular are bedeviling for web writers. If you want to
write about 'AT&T', you need to write '`AT&T`'. You even need to
escape ampersands within URLs. Thus, if you want to link to:
http://images.google.com/images?num=30&q=larry+bird
you need to encode the URL as:
http://images.google.com/images?num=30&q=larry+bird
in your anchor tag `href` attribute. Needless to say, this is easy to
forget, and is probably the single most common source of HTML validation
errors in otherwise well-marked-up web sites.
この書き方は「箇条書きを含む段落」を表現した例2のものと全く同じです。前述の通り、「段落が表現できるか」という問題の下では箇条書きもコードブロックも同じように扱えるはずです。従って、元祖Markdown（Gruberの定義）では「例2のコードで図1の文章が表せる」という確証がもてます。
CommonMarkではどうか
CommonMarkでは「原則として元祖Markdownを引き継ぐ」という方針をとっています。CommonMarkの規定の中に「段落とは何か」という議論が一切出てこないことを考えると、この点に関しては元祖Markdownと全く同等であると考えていいでしょう。
※規格の5.3節に現れる例などが補強になると思われます。
ここまでのまとめ
「箇条書き（などのブロック要素）を含む段落」はMarkdownで表せること、さらに、「直観的に予想される書き方」がそのまま通用するということがわかりました。
ところが、「箇条書きを含む段落」を含む文章をMarkdownで実際に扱おうとすると、文章のスタイルによってはレンダリングに関して問題が生じることがあります。これについては後日に別の記事（たぶんアドベントカレンダーの記事）で述べる予定です。