<figure> について（やや堅苦しく）考える

> *[UPDATE: 20161027] 誤訳の修正と、コメントを受けて定義変更可能性を追記。訂正箇所は打ち消し線で記述*

## TL;DR

1. \<figure\> ってなんだ
2. 世の中の人はどう使っているのか調べてみた
3. \<figure\> 要素は注釈である
4. 実例
5. おわりに

## \<figure\> ってなんだ

HTML5から追加された `<figure>` 要素で、写真や絵や図を用いる際によりセマンティックな（文章構造を正確に伝えられる）マークアップができるようになった、と言われている。以下がスタンダードな使い方だ。

```HTML
<figure>
  <img src="hoge.jpg" alt="hoge">
  <figcaption>hoge</figcaption>
</figure>
```

ところが、どうも明確な信念を持ってこの `<figure>` タグを運用しているHTMLマークアップエンジニアみたいな人にはなかなか出会うことがない。そこで、個人的な **信念** を述べてみたい。

## その前に、世の中の人はどう使っているのか調べてみた

名前や所属企業は伏せるが、数名の同業者にアンケートをとってみた。

1. *使ったことがないし、使おうとも思わない*：**ある意味正しい**。意図もよくわからないまま「新しい機能だから」と使い始めて不具合が起きたら本末転倒である。だが、思考を停止するのはベストではないことは確かだ。
2. *`<img>` タグを入れる際は必ず `<figure>` で囲んでいる*：**ちょっと待て**。 `画像イコール<figure>` ではない。[W3Cの公式な説明](https://www.w3.org/wiki/HTML/Elements/figure)によると、 *self-contained and typically referenced as a single unit* とある。つまり、**自己完結していない画像（ただのアイコンや本文と何ら関係性のないバナー広告など）は、 `<figure>` ではない** のである。
3. *`<figcaption>` が入れられそうなら `<figure>` だし、画像だけの場合は `<p>`* ：これは **明確に誤り** である。同じくW3Cの公式な説明を参照すると、 *This content __may__ have a caption, typically the <figcaption> element* とある。そもそも `<figcaption>` の無いパターンがあらかじめ想定されたタグなのだ。

## \<figure\> 要素は注釈である

同じくW3Cの公式の説明によると、以下のようなケースでの使用が想定されている。

* annotate illustrations: 注釈の絵
* diagrams: 図
* photos: 写真
* code listings: コードの列挙

そして、以下のような補足がある。

* *When the <figure> element is referred to from the main content of the document, it enables such content to be moved away but without affecting the flow of the document.*: （要約）その要素がなくなっても、本節に影響を与えない。
* *That's why authors should use labels to refer to figures, rather than such relative references (ex.: "See figure no.3" instead of "See below").*: （要約）だから、~~「図３を参照」ではなく「詳しくは以下」のように~~「詳しくは以下」ではなく「図３を参照」のように、~~いっしょに消せるラベルとして~~相対的な配置ではなく、絶対参照のラベルとして使うべきだ。*（註：絶対参照であるべきとの記述は、[W3Cの別なガイドライン](https://www.w3.org/community/webed/wiki/HTML/Elements/figure)では記述が削除されており、定義仕様が変更となる可能性が示唆されている。）*

すなわち、本文上で必ずユーザが参照しなければいけない重要な情報ではなく **なくてもいいけど、あったらより詳しく内容がわかる補足情報・説明文・解説** が `<figure>` の役目であり、そして **必ずしも絵や写真だけのために用いられるわけではない** ということだ。

## 実例

### 本文を補足する写真や絵を例示する場合（その写真や絵がなくても、本文が成立する）

```HTML
<section>
  <p>
    秋は空気も澄んでいて、空も高く感じられ、馬も肥えるような収穫の季節でもある。<br>
    杜審言の詩『蘇味道に贈る』に「雲浄くして妖星落ち、秋高くして塞馬肥ゆ」とあるように、<br>
    清々しくもミステリアスな季節である。
  </p>
 
  <figure>
    <img src="image.jpg" alt="美女">
    <figcaption>美女は、秋空の映える景色ではより一層美しいものである。</figcaption>
  </figure>
</section>
```

### 本文で述べているシステムやダイアグラムを補完する図を例示する場合（その図がなくても本文は成立するが、あったらよりわかりやすい）

```HTML
<section>
  <h2>クリスマスまでに彼女を作る方法</h2>

  <p>簡単である。</p>
  <ol>
    <li>イケメンになる</li>
    <li>彼女を作る</li>
  </ol>
  <p>詳しくは解説の図を参照されたい。</p>

  <figure>
    <img src="image.jpg" alt="クリスマスまでに彼女を作る方法の解説">
  </figure>
</section>
```

### 本文で述べているデータを補完する表組を例示する場合

```HTML
<section>
  <p>
    アンケート対象の男女200人に現在の交際関係・恋人または婚約者がいるかどうか尋ねたところ、
    「現在、婚約者がいる」と「現在恋人がいる」を合計した割合では、
    日本は調査対象国5か国の中で最も低い割合となっている。（図2-2-12）
  </p>
  
  <figure>
    <table>
      <caption>「現在、婚約者または恋人がいる」人の割合の変化</caption>
      <thead>
        <tr>
          <th></th>
          <th>2005年</th>
          <th>2010年</th>
        </th>
      </thead>
      <tbody>
        <tr>
          <th>日本</th>
          <td>32.1%</th>
          <td>24.6%</th>
        </tr>
        <tr>
          <th>アメリカ</th>
          <td>37.2%</td>
          <td>40.0%</td>
        </tr>
        <tr>
          <th>フランス</th>
          <td>17.4%</td>
          <td>28.8%</td>
        </tr>
      </tbody>
    </table>
    <figcaption>2-2-12: 内閣府「少子化社会に関する国際意識調査報告書」より</figcaption>
  </figure>
</section>
```

### ソースコードの例示

```HTML
<section>
  <p>ES2015より、明示的にletによるブロックスコープの宣言ができるようになった。</p>

  <p>たとえば以下のように記述できる。</p>
  <figure>
    <code>
      <pre>
        let func = () => {
          let variable;
          variable = 'hoge';
        }

        // 以下はブロックスコープ外のためundefinedが返される。
        console.log(variable);
      </pre>
    </code>
  </figure>
</section>
```

## おわりに

原理主義を強要しているのではない。最初に述べたように、「使ったことがないし、使おうとも思わない」タイプもひとつの選択であり、意味がある。開発者にとって重要なことは、自分の選択が、自分の開発に妥当か、そして理解を得られるか、ということである。（少なくとも本記事で述べていることは、ほぼすべてのクライアント・プロダクトオーナーにとっては妥当ではないし、理解されない。）さらに、実際に例示したいくつかの例も、なんだか冗長なだけであまり保守性が高くないかもしれないと、書きながら思っていたのもまた事実である。

ただひとつ言えることは、マークアップの情報設計がしっかり考慮されたものであれば、コードを見ただけで、そのセクション・要素が、文書全体でどういう位置付けで配置されているのかを判断できるはずだ、ということである。これは、多くの共同開発者にとってメリットとなるだろう。