要約

  • 2019年12月のW3C初公開草案は、サイトがテキストやURLを渡し、利用者側の環境が共有先の選択画面を出すという役割分担を示した。
  • 2023年5月のW3C勧告はファイル共有、canShare()による確認、利用者の操作を起点にしたshare()の流れを記述した。

「この記事を送る」ボタンの隣に、サービス名をずらりと並べたサイトを思い出してほしい。読者が使う送り先がそこにあるとは限らない。編集者が人のスマートフォンを見たこともないのに、「あなたの友だちはこの辺でしょう」と住所録の代役を務める。なかなか大胆な接客である。

端末には端末の事情がある。どんなアプリが入り、どんな共有先が使え、画面上でどう見せるかを知っている。サイトが知っているのは記事の見出し、短い説明、URLだ。その二つの知識を持ち寄るための窓口がWeb Share APIになった。サイトが荷物を差し出し、端末が扉を並べ、最後に読者が選ぶ。

2019年12月17日のW3C初公開作業草案は、navigator.share()にタイトルやURLなどを渡す例を載せた。呼び出しはボタンを押す操作から始まり、ユーザーエージェントが共有先を選ぶ画面を出す。初期のShareDataにはタイトル、テキスト、URLがあった。サイトに求められたのは中身の準備で、端末内のアプリ一覧を追いかけることではない。

この設計には、少し上品な遠慮がある。記事を出す側は、読者がどこへ送るかを先回りして決めない。読者はメッセージに貼るか、自分のメモに置くか、その場の選択肢から決められる。同じリンクでも、読者にとっての使い道は一つではない。サイトが全部の扉に自分の看板を付ける必要もない。

2023年5月30日のW3C勧告では、共有するデータにファイルも含まれる。仕様の例はFileをfiles配列に収める。navigator.canShare(data)は、用意したデータを共有できるかを画面を開かずに確認する手段だ。ボタンを置く前の点検に使える。本番の受け渡しを始めるのはshare()で、利用者の操作が伴う。

利用者の操作という条件は飾りではない。共有画面が勝手に飛び出すのでは、読書中に窓口係が突然肩をたたくのと変わらない。勧告は有効な操作、進行中の共有、キャンセルや拒否の扱いを記述する。サイト側はボタンを押されたときに適切な内容を渡し、読者が画面を閉じたら普通に記事へ戻ればいい。送り先を選ばなかった人に説教する必要はない。

勧告が想定する共有先には、環境に応じてアプリ、ウェブサイト、連絡先などがある。画面の形は端末ごとに違う。あるスマートフォンではおなじみのシートが現れ、別の環境では別のメニューになる。共通なのは見た目の制服ではなく、サイトから利用者側への引き渡し方だ。

W3Cの公開履歴を見ると、初公開草案は2019年12月、勧告は2023年5月である。この間にファイルや事前確認を含む記述が整った。仕様書は厚みを増しても、街角の場面は変わらない。サイトが封筒を出し、端末が配達先の候補を見せ、人が指を置く。

だから共有ボタンの質は、画面を出せるかだけでは測れない。タイトルは本当にその記事を表しているか。URLは読者が送りたいページへ着くか。ファイルはその端末で扱えるか。窓口を開く前に答えられる問いは、サイトが自分で答えるべきだ。

受け取る人を決めるのは、記事を書いた人ではない。サイトができる最良の仕事は、正しい宛名のない包みをきれいに用意し、届け先を決める人へ渡すことだ。