Catyプロジェクトを始めたとき、プログラマとデザイナの「干渉が少ない分業」が大きなテーマでした。僕らが採用した基本的な方針は次のものです。
このとき、テンプレート言語にプログラミング言語の能力を持たせてしまうと分業にならないので、テレンス・パー（Terence Par）の理論と提案に従い、戦略的低機能テンプレート言語を提供します。
この方法がマズイとはまったく思ってませんが、別な分業形態も準備した方がよいと最近思っています。「マイクロフォーマットとクリーンHTML」で説明したクリーンHTMLは、その「別な分業形態」におけるプログラマ／デザイナ境界となるものです。境界とは、2つの作業を分離するための手段であり、2つの作業のあいだで受け渡すデータのことです。
クリーンHTMLを使った分業は次のようになります。
- プログラマはクリーンHTMLフラグメントの生成に専念する。
- デザイナは生成されたクリーンHTMLフラグメントに対して、CSSとJavaScriptによりスタイルや視覚効果を与える。
JSONデータを境界に使う場合は、プログラマとデザイナ（マークアップもする人）が合意すべきことは、JSONのデータ型スキーマです。一方、クリーンHTMLフラグメントを境界に使う場合は、HTML要素構造、特に要素のIDとクラス名を合意します。この合意事項は、「マイクロフォーマットとクリーンHTML」に事例を示したような（以下に再掲）CSSスタイルシートのスケルトンにより文書化できるでしょう。
/* 人物情報のトップレベル */ div.vcard {} /* メールアドレス */ div.vcard li.email {} /* URL */ div.vcard a.url {} /* ==== 補助的な要素 ==== */ /* メールアドレスを列挙するリスト */ div.vcard ul.email-list {} /* URLを列挙するリスト */ div.vcard ul.url-list {} /* URLを列挙するリストの項目 */ div.vcard ul.url-list li {}
デザインの都合から、合意した要素構造で不足があるなら、JavaScriptでDOM操作をすれば変形や追加もできます。しかし、ゴリゴリJavaScriptを使うのは、なんか分業の趣旨に反する感じがします*1。できるだけCSSの範囲内で見た目の調整をするほうが望ましいでしょう。擬似クラス（:hover, :first-childなど）、疑似要素（:after, :beforeなど）、contentプロパティなどを組み合わせると、CSSだけでもけっこうな事ができるようですよ、詳しくは知らんが ^^;。
それで、マイクロフォーマットがこれにどう関わるかというと； プログラマ／デザイナの合意事項となるIDや*2クラス名を毎度毎度その場でローカルに決めるのは面倒で大変ですよね。既に決めてある標準があればそれに従えばいいのです。つまり、クリーンHTMLフラグメントの標準ボキャブラリーとしてマイクロフォーマット仕様が使えるだろう、ってことです。
要素構造やクラス名を新しく決める必要があるときでも、マイクロフォーマットのマークアップ・デザインバターンは参考になります。名前空間が使えないので、名前衝突を避ける工夫とかが必要ですが、それにしても白紙から考えることに比べればずっとずっと楽です。
マイクロフォーマットのスキーマに厳密な定式化を与えれば、「JSONデータ⇔クリーンHTMLフラグメント」の構造的・意味的な等価性は保証できるので、JSON境界のときと比べてプログラマの負担は増えません。デザイナとしては、直接タギングによるデザインが封じられるので、もどかしいかも知れません。この点が懸念事項です -- 「タギングだせー、やっぱCSSでしょ」の傾向に期待。
もし今後、「要素構造の単純化＋CSSデザインの拡大」がさらに潮流となるなら、プログラマ／デザイナ境界をクリーンHTMLにずらしてもいいのじゃないか、というのが今の僕の考えです。
*1:JavaScriptで頑張るくらいなら、デザイナにテンプレート操作を開放して、テンプレートを直すほうが楽で早いでしょう。
*2:取り消し線を入れたのは、IDを取り決めるのはそんなに大変でもないかな、と思ったので。連番とかでもまーなんとかなりますから。
