第26章 HTML はどこへ向かうのか
開閉する説明欄を作るとき、最初からクリック処理を書いていないでしょうか。HTML の変化を追う価値は、新しいタグを暗記することだけではありません。自分で実装していた処理を、ブラウザの標準機能に任せられるかを判断することにもあります。
26.1 details で標準機能を試す
次は、補足説明を開閉する本文断片です。
<details>
<summary>持ち物を確認する</summary>
<p>筆記用具と参加証をお持ちください。</p>
</details>
details は開閉できる補足情報、summary はその見出しです。独自の JavaScript を書かなくても、summary を操作して開閉できます。初めから開くなら details に open 属性を付けます。open="false" では閉じないことは、第11章のブール属性の話と同じです。
汎用的な div から作るなら、開閉の処理に加え、キーボード操作や状態の通知も設計する必要があります。用途が details に合うなら、標準の意味と操作を利用できるため、自作する部分を減らせます。ただし、タブ切り替えやメニューなど、異なる UI の代用品にしてよいわけではありません。
26.2 存在確認と利用確認を分ける
基本的な API の存在は、たとえば次の式で調べられます。
'open' in document.createElement('details')
この結果が true でも、すべての操作が期待どおりであることや、支援技術との組み合わせまで保証するわけではありません。採用する際は、対象ブラウザの対応を確認し、実際のページで次を試します。
- JavaScript を追加せず、クリックとキーボードで開閉できるか。
- 見出しへフォーカスした位置が分かり、開閉状態を支援技術で確認できるか。
- CSS を付けたあとも操作や内容の読み取りを妨げていないか。
- 印刷など別の利用経路で、閉じた内容をどう扱う必要があるか。
標準機能を使えば、設計と確認が不要になるのではありません。基本の振る舞いをブラウザに任せたうえで、自分の用途との適合を確認するのです。
26.3 新機能を追うときの順序
仕様に名前が載ったこと、実装されたこと、利用者の環境で使えることは別です。新しい機能を見つけたら、まず仕様で用途と制約を読み、次に対応状況を調べ、最後に対象環境で小さく試します。変更の理由を知りたいときは、第23章で紹介した issue や pull request をたどります。
Living Standard という更新方式は、未来の機能をすべて予告しているわけではありません。ブラウザの実装、利用者の要求、互換性の問題に応じて、説明や処理を更新し続ける仕組みです。将来の予想を固定した一覧より、この調べ方を持っているほうが長く役立ちます。
26.4 不思議な挙動を、次の判断へつなげる
ソースと DOM が違えばパース規則を調べ、古い要素を見つければ著者向けの状態と互換実装を分け、要素を選ぶときは読み手へ渡す意味を考える。本書で扱った知識は、こうした判断のために使えます。
HTML の奇妙さには、タグ省略の構文、既存ページとの互換性、複数の読み手への情報提供など、異なる理由があります。すべてを一つの設計思想で片づけず、目の前の挙動がどの規則によるものかを確かめる。その姿勢が、これから変わる HTML にも付き合う方法になります。