meta-contactを使わずに連絡先をマークアップできないか

blink-devにこんなメッセージが。

たとえばおさいふ落とした時に銀行やカード会社に連絡とかしづらいから、電話番号、メールアドレス、住所を <meta name="contact"> なるものにぶっこんで、緊急な際にそのWebサイトに行く→ブラウザのメニューから「Call」ですぐ連絡できるよ！といったアイデアの実現をSamsungが考えているようで。そうですか……

なんでもこの電話、メール、住所のタプルは複数指定できるらしい。

<meta name="contact" content="Chicago: +1-555-555-5555 abc@xyz.com '5844 South Oak Street, Chicago, Illinois'; Brookfield: +1-444-444-4444 def@xyz.com '2341 Cherry Lane, Brookfield, Illinois'; Naperville: +1-333-333-3333 jkl@xyz.com '515 W. Jefferson, Naperville, Illinois 60540'">

おおう……

先月にはWHATWGでだいたい同じような提案をしていたようで。

この当時は website-mail, website-number, website-address と別のプロパティだったのにまとめられてしまった。どうしてそうなった。

「website-mail は <link> に mailto: なURLにせいや」というコメントがあったんだけど「リンクタイプの拡張は仕様書き換えないといけないし…」という理由で <meta> らしい。違うんだけどさ。でもこういう標準化トラックの誤解はけっこうあるのだろうなあ。わかりやすさが必要ですね。

いまあるものでどうにかできないか

「電話番号」「メールアドレス」「住所」というプロパティを考えると、すでにボキャブラリはある。vCardとかSchema.orgとか。HTMLへの埋め込みについても、Microformats、Microdata、RDFaとかがある。Microformatsはvisible metadata志向なのでとりあえず除外しよう。

Microdata

Microdata＋Schema.orgだとこうなる。

<meta itemscope itemtype="http://schema.org/Organization" itemref="tel email adr">
<meta itemprop="telephone" content="+810000000000" id="tel">
<meta itemprop="email" content="foo@example.com" id="email">
<meta itemprop="location" content="123 Bar St. ..." id="adr">

<meta> でやろうとすると入れ子にできないので itemref でプロパティそれぞれにつけた id を参照しないといけない。結果ちょっとつらくなる。あと itemscope のための <meta> もうれしくないね。 location のExpected Typeは PostalAddress か Place なので本当はもういっこ itemscope が増えてしまうのだけど、ちょっと楽をした。

Microdataもコンテンツがそれなりに構造化されてマークアップされていることをどこかで求めているので、フラットな meta だけだと無理がくる。入れ子にできたところで開発者は入れ子を嫌う（偏見）ので、受けが悪そうな気がする。

RDFa

RDFaだとこうかなあ。

<meta typeof="schema:Organization" resource="#contact">
<meta property="schema:telephone" content="+810000000000" resource="#contact">
<meta property="schema:email" content="foo@example.com" resource="#contact">
<meta property="schema:location" content="123 Bar St. ..." resource="#contact">

すっきり書けるかなと思ったけどそんな変わらなかった。

まずはSchema.orgの名前空間。RDFa 1.1だとschema接頭辞が組み込まれてるので vocab を省ける。ただ接頭辞が長いので名前がちょっと長たらしい。

<meta> が入れ子にできない問題は resource 属性でてきとうなURIをリソースに与えプロパティから参照させることで解決。Microdataの itemref は itemscope からプロパティという一方向で、かつ id を再利用するのでプロパティそれぞれに別個の識別子をふらないといけないのがだるい。RDFaは resource なる新しい属性を導入したので、双方向にできている。

あと、最初に typeof のためだけの <meta> を入れてるけど、この部分はプロパティのある要素に移動できるので、要素の数は3つに減らせたりする。

<meta property="schema:telephone" content="+810000000000" typeof="schema:Organization" resource="#contact">
<meta property="schema:email" content="foo@example.com" resource="#contact">
<meta property="schema:location" content="123 Bar St. ..." resource="#contact">

3要素に全部 typeof 入れられもする。そうするとひとつの <meta> に依存しない利点がある。しないけど。

データ的には嬉しくないだろうけど、typeof とっちゃうのもありかもしれない。

<meta property="schema:telephone" content="+810000000000" resource="#contact">
<meta property="schema:email" content="foo@example.com" resource="#contact">
<meta property="schema:location" content="123 Bar St. ..." resource="#contact">

こうすると、resource がちょっと余計に見えるけど、まあお約束ということにすれば。

というわけで、各プロパティが分かれてる場合、RDFaだとただの <meta> とだいたい同じくらいの楽さで同じことができそうではある。Schema.orgだとほんとはContactPointのほうが良さそうだけど、まあ。

<meta name="contact"> はワンライナー的なものだからできない。こういう時にRDF/XMLみたいな要素としても属性としても書けるっていうバーサタイルなものが欲しくなるけど、不幸しか呼ばないだろう。

フラットになると抜けるもの

ただまあ、MicrodataやRDFaつかうとなると、MicrodataやRDFaの仕組みを実装しないといけない感がでてしまうので敬遠されるだろうなあという気はする。ただの <meta> にすれば、特定の名前に対して処理を決めうちしてやればいいので楽だ。resource とかも必要ないし。

ただ「情報」として考えると無理がある。さっき「フラットな <meta>」と書いたけど、これはWebページというスコープが暗黙にあるからフラットになっている。連絡先はページにも関連するかもしれないけど、もとの提案は銀行の支店とかを考えているようなのでページとは直接関係しない情報だ。ページに直接関わらないものを <meta name="foo"> に押し込むような名前と処理を定義してもいいんだろうけど、だいぶ乱暴ではないか。

拡張ごとにマイクロシンタックスを増やすのは、健康的ではないよね。そういう点でOGPはだいぶ頑張ったしえらいなという気はする。

もうちょっと自由度が低くて、でも書くぶんにはふつうの <meta> と変わらないRDFaのサブセットがあればいいのかもしれない。resource さえ許容できれば、さっき書いたのでだいぶいい線いってるとは思うけど。