「箇条書きを含む段落」をMarkdownする話

>   これは「[Markdown Advent Caleandar 2020](https://adventar.org/calendars/4964)」の5日目の記事です。

## 某キータの某質問と某回答

先日、Qiitaの質問機能において次のような質問（意見交換）が投稿されました。

  * [Markdown文書で良く見かけるこの箇条書きの記述は文法エラーじゃないですか？][question]

質問は以下の図のような**「箇条書きを内部に含む段落」**に関するものでした。

---

![箇条書きを内部に含む段落](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/14550/4593bc98-a77b-eaf6-e820-ac346a287bfc.png "箇条書きを内部に含む段落")
<font color="#3F9200"><b>図1：箇条書きを内部に含む段落</b></font>

---

投稿者の問題意識は「このような段落の構成は日本語の文書として正当か否か」というところにあり、その考察の際にHTMLやMarkdownとの対比を行っています。

この質問について、私は以下の趣旨で[回答][answer]を投稿しました。（詳細については実際の回答を参照してください。）

 1. 日本語の文書構成の慣習では「箇条書きを含む段落」は許容されていると思われる。<br>※これは「自分の意見」です。
 2. HTML5では「文章構成上の段落[^paragraph]」「HTMLの段落(paragraph)」「p要素」は別個のものとして扱われている。
 3. 2の扱いのため、「箇条書きを含む段落」をHTML5で表すことは**可能**である。<br>※2と3は「[HTML5の規格書の記述][spec][^is-spec]を根拠とした事実の主張」です。

[^paragraph]: この「（文章構成上の）段落」は、特定の規格や技術には無関係に存在する、日常的な意味での「段落」を指すことに注意してください。欧米流の“paragraph writing”を初めとして「段落」の構成手法は様々なものがあるため、「何が『段落』であるか」の画一的な定義はできません。「文章の著者が『段落』として表現したものが『段落』である」ということになるでしょう。この記事の議論は「文章は『段落』から構成される」ことを前提としています。
[^is-spec]: ただしNoteの中の記述であるため「規定」であるとはいいがたいのも確かです。

実は、この回答の続きの話として**「Markdownに関する話」**を書こうとも考えていたのですが、元の投稿者の問題意識から大きく外れてしまうことを危惧して割愛しました。その「Markdownに関する話」を「[Markdown Advent Calendar][advent]」の記事として投稿します。

※以下では、「HTMLやMarkdownの定める段落」と明確に区別するため、「文章構成上の段落」のことを**「<ins>段落</ins>」のように下線付で表記する**ことにします。

※この記事では、Markdownの数ある方言の中で特に「Gruberによる[“元祖Markdown”][gruber]」と「[CommonMark][commonmark]」を考察対象とします。この2つに由来する方言で大きな意味論上の変更を加えていないものであれば、同じ議論が成立するでしょう。

## 「箇条書きを含む<ins>段落</ins>」はMarkdownできるか

ます最初に、「箇条書きを含む<ins>段落</ins>」を**Markdownで表すことが可能であるか**を考察します。

### HTMLできるならMarkdownできるはず

例の「[回答][answer]」で述べた通り、図1の文章は以下のようなHTML5のコードで表せます。

```html:例1(HTML)
<p>これは</p>
<ul>
<li>A</li>
<li>B</li>
<li>C</li>
</ul>
<p>の3つの利点を持ちます。</p>
```

この例1のHTML5の文書をMarkdownに書き直せ、と言われると、多くの人は次のコードを思い浮かべるでしょう。

```markdown:例2(Markdown)
これは

  - A
  - B
  - C

の3つの利点を持ちます。
```

この例2のコードは本当に「図1の文章を表している」と見なしていいでしょうか？

この疑問に対する答えを出すには「Markdownにおいて『段落(paragraph)』とは何なのか」について精査する必要がありそうです。といっても、元祖MarkdownにしてもCommonMarkにしても「段落とは何なのか」についての明示的な規定はありません。ただし、元祖Markdownは「HTMLの記述の代用」として考案されたものであり、またCommonMarkの規格は「文書構造を示す手段としてHTMLコードを用いる」という方針（[1.3節][commonmark-about]）をとっています。これを考慮すると、**「Markdownの『段落』の意味はHTMLのそれを引き継ぐ」**と見なすのが妥当でしょう。つまり、「例1のHTMLコードと例2のMarkdownコードは同じ構造を表している」と見なすことができて、かつ「例1のHTMLは図1の文章を表している」のであれば、「例2のMarkdownのコードは図1の文章を表している」も成立するはずです。

### イチャモンを入れてみる

ただしこの議論には穴があります。元祖Markdownが造られたのは2004年であり、このときにはまだ**HTML4が通用**していました。となると、元祖MarkdownはHTML4の意味論を持っているとも考えられます。このことは、`**...**`の記法（これはstrong要素に対応します）のことを「重要（important）」ではなく「強い強調（strong emphasis）」と呼んでいることからも裏付けられます。

一方CommonMarkはどうかというと、やはり`**...**`を「強い強調」と呼んでいる（[6.4節][commonmark-emph]）ので、HTML4が踏襲されているように見えます。

例の[回答][answer]で述べた通り、HTML5の段落の定義はHTML5になって初めて定められたものであり、実際、HTML4の時代には「箇条書きを含む<ins>段落</ins>」が表現できるか否かが不明瞭だったのです。となると、HTML5の記述を根拠とした議論は不適切であるという批判はありえるでしょう。（とはいえ、私見としては、今の時代にHTMLコードをわざわざ「規定が不明確なHTML4の意味論」で考える必然性は乏しいと思いますが。）

### Gruberかく語りき

「箇条書きを含む<ins>段落</ins>」をMarkdownで表せるという議論を補強するために、改めてGruberによる元祖Markdownの規定を調べてみます。

* [Markdown: Syntax][gruber-syntax]

よく読むと、この規定の文書自体が「コードブロックを含む<ins>段落</ins>」を含んでいます。

> Ampersands in particular are bedeviling for web writers. If you want to write about ‘AT&T’, you need to write ‘`AT&amp;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&amp;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.

コードブロックは箇条書きと同様に「ブロック要素」の一つであることを考えると、「箇条書きを含む<ins>段落</ins>」の問題は「コードブロックを含む<ins>段落</ins>」の問題と同じものといえます。

さらに注目すべき点として、この文書の冒頭には「この文章自体がMarkdownで書かれている」と明記されています。

> NOTE: This document is itself written using Markdown; you can see the source for it by adding ‘.text’ to the URL.

このことから、Gruberは「元祖Markdownは『コードブロックを含む<ins>段落</ins>』を表すことができる」と考えていることが推定できます。実際に当該の文書のMarkdownソースを見てみましょう。

* [Markdown: Syntax（Markdownソース）](https://daringfireball.net/projects/markdown/syntax.text)

```markdown
Ampersands in particular are bedeviling for web writers. If you want to
write about 'AT&T', you need to write '`AT&amp;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&amp;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.
```

この書き方は「箇条書きを含む<ins>段落</ins>」を表現した例2のものと全く同じです。前述の通り、「<ins>段落</ins>が表現できるか」という問題の下では箇条書きもコードブロックも同じように扱えるはずです。従って、元祖Markdown（Gruberの定義）では「例2のコードで図1の文章が表せる」という確証がもてます。

### CommonMarkではどうか

CommonMarkでは「原則として元祖Markdownを引き継ぐ」という方針をとっています。CommonMarkの規定の中に「段落とは何か」という議論が一切出てこないことを考えると、この点に関しては元祖Markdownと全く同等であると考えていいでしょう。

※規格の[5.3節][commonmark-lists]に現れる例などが補強になると思われます。

## ここまでのまとめ

**「箇条書き**（などのブロック要素）**を含む<ins>段落</ins>」はMarkdownで表せる**こと、さらに、「直観的に予想される書き方」がそのまま通用するということがわかりました。

ところが、「箇条書きを含む<ins>段落</ins>」を含む文章をMarkdownで実際に扱おうとすると、文章のスタイルによってはレンダリングに関して問題が生じることがあります。これについては後日に別の記事（たぶん[アドベントカレンダー][advent]の記事）で述べる予定です。

[question]: https://qiita.com/chuui/questions/dd74ccf6024bf4bf4cfb
[answer]: https://qiita.com/chuui/questions/dd74ccf6024bf4bf4cfb#answer-480f36632376ec1d2463
[advent]: https://adventar.org/calendars/4964
[gruber]: https://daringfireball.net/projects/markdown/
[gruber-syntax]: https://daringfireball.net/projects/markdown/syntax
[commonmark]: https://spec.commonmark.org/0.29/
[spec]: https://html.spec.whatwg.org/#the-p-element
[commonmark-about]: https://spec.commonmark.org/0.29/#about-this-document
[commonmark-emph]: https://spec.commonmark.org/0.29/#emphasis-and-strong-emphasis
[commonmark-lists]: https://spec.commonmark.org/0.29/#lists