John Allsopp著「マイクロフォーマット」の話題からです。

この本は（純粋に）技術面では (X)HTML と CSS の話題なのですが、テクニカルな面でのクライマックスは、イベントをマークアップする hCalendar を、二次元のタイムテーブルとして表現された複数のイベントに対して適用するにはどうすればいいか？という話題です。要するに

	会場１	会場２
10:00～12:00	分科会Ａ	分科会Ｂ
13:00～15:00	分科会Ｃ	分科会Ｄ
15:00～16:00	総会（会場１にて）

みたいなタイムテーブルの個々の要素（計５つ）について、それぞれを個々の vevent としてマークアップするためのテクニックの話です。でやはりこれを、DRYなマイクロフォーマットらしく

HTML のあまり知られていない属性をうまく活用

して乗り切っているわけです。まあ、

ふ～ん、こんなんあるんだ

と思って読んでしまえばソレまでなのですが、少し面白がって調べて見ることにしましょう。

というのは、

もしマイクロフォーマットが「無益」ではなくて「有害」であるとするのならば、その根拠は「多重マークアップ」という点

だろう、というのがまず大前提の問題としてあるからです。マイクロフォーマットは、周知のように既存の(X)HTMLボキャブラリを「乗っ取る」かたちで自らのマークアップを行います。ですから、結果として、

HTMLとして正しく、かつマイクロフォーマットの構造としても正しい

状態になるように、注意深くマイクロフォーマットの定義が定められているわけですが、ある意味、これが実現できるケースは「ラッキー」であり、一般に要求するのは難しいのでは？というのが、（もしあるとすれば）有害論の根拠なのですね。まあ、ここらへんの議論は「多重マークアップ」とか「平行文書構造」とか呼ばれるもので、例のキマイラ飼育記（「Microformatsと多重マークアップ」）で指摘していたりします....まあここらへんマイクロフォーマットの本質なのでどうしようもないところなのですが、特に先ほどのタイムテーブルの例だと、

テーブルヘッダ(TH)として、会場情報（横）と時間情報（縦）があり、個々の TDセルが具体的なイベントの中身である

という「HTMLの構造」が、

個々のイベントを示す hevent でマークアップされた（TDセルの）要素の中に、時間を示す dtstart, dtend、会場を示す location でマークアップされた要素がある

という「マイクロフォーマットの構造」と整合性が取れない状態になっているわけです！とはいえ、こういう「タイムテーブルのレイアウト」は非常に一般的なものであるに違いありません。レイアウトは正しいわけです....

まあ、次のような（姑息な）解決方法はあります。

1. 1. TDセルの中に、表示上は CSS で隠すかたちで、時間と会場のマークアップを入れる
2. 2. include デザインパターンを使ってヘッダに書かれた時間と会場のマークアップを引用する

....が、Allsopp はそうではない「真正面からの突破」をしてます。それが TD,TH のあまり使われていない属性である、headers, scope, axis を使うというやり方です。

まあ、具体的に「マイクロフォーマットではこうマークアップするんだ！」というのを知りたい人は、Allsopp の本を買いなさい（まあ、このエントリのソースを見てくれてもいいんだけどね）。この知られていない属性をググってみると、一番キッチリした説明は「神崎先生」にありました（「テーブルとアクセシビリティ」）。一般にはまだそれほど使われていないこの３つの属性ですが、しかしマイクロフォーマット以外のある「使い方」で、とっても重要な属性になりそうなのです....それはですね、

音声ブラウザ

なのです。つまりアクセシビリティの問題であり、大きなテーブル構造を読み上げた時、「そのセルがどういうものか」を聞く人にとって判りやすく「うまく読み上げる」手がかりになる属性なのです。勿論規格としては、「テーブル構造の論理的な関係を明示する」ように定義されていますが、この「論理的な関係」を記述する属性が、マイクロフォーマットと音声ブラウザの双方にとって非常に有益なものだったりするわけです！　たとえば、

scope属性

row か column の値を取って、そのセルがどちらの方向に対する見出しか明示する。

headers属性

その内容セル(TD)が、どのヘッダセル(TH)と関係を持つかを、ヘッダのid属性を参照するかたちで、内容セルに指定する。

axis属性

そのヘッダセルが、どういう性質の見出しであるかを説明する。たとえば上記のテーブルの例だと、「会場」とか「時間」といった説明的な内容がこの属性の値になる。

まあ勿論これらの属性は、フツーの（非音声）ブラウザでは何の意味もない属性です。しかし、今後特に「ユニバーサルデザインを心がけてます」と言いたい人にとっては、かなり重要な属性になるのかもしれません....

「アクセシビリティ」というと、マイクロフォーマットでは例のabbr デザインパターンと音声ブラウザの問題で、

厄介....

というイメージでしたが、ちょっと認識を改めました。あらゆる面で、

論理的な関係を記述する

というのは、根本的なメリットがあると考えるべきなのですね。

 けど逆にこういう headers 属性の適切な処理を、アグリゲータはちゃんと実装しないといけない......逆に厄介、ですね、ふう。