現在の Web サイトの制作では、主に次のようなプロセスが多い。
コンテンツ（ドキュメント）作成 → Photoshop や Fireworks を使った画面設計（装飾も同時） → HTML CSS コーディング。
随分前からいわれていることなのだけれど、より品質を重視したプロセスは以下のようなものになるのではなかろうか。
文書設計 → コンテンツ（ドキュメント）作成 → 画面設計 → インタラクションデザイン → ドキュメントの構造化（ HTML コーディング） → Photoshop や Fireworks を使った視覚デザイン → CSS コーディング。
個々のプロセスをより具体的にすると、
前回書いたとおり、文書設計は表現対象とその表現形式の決定なので、これは HTML の構造化とは違う。
コンテンツ作成は設計に基づいて具体的に表現していく段階。
画面設計・インタラクションデザインはコンテンツをどのように表現するのかの設計。
表現された文書を HTML で構造化。
構造化されたコンテンツと決定されたインタラクションにたいして、どういった視覚表現が最適かを考える。
決定された視覚表現を CSS で再現。
になる。
コストを削減するなら、視覚表現はコンテンツの前に定型化された構造にあてていってもいいのかもしれない。ただ、それはコンセプトのない表現になるので、多少の意味があったところで、ただの装飾であり、絵でしかないので、決まりきった退屈なものしかできないだろうけれど。
まあこの際そんなことはどうでもよいとして、なぜ HTML と CSS を別のプロセスとしなければならないのか。
その答えは表現の目的が異なるから。
HTML は文書の構造と内容の表現を行い CSS は視覚効果の表現を行う。
目的が違えば自ずと別のプロセスを必要とする。
インタラクティブな表現に複雑な構造を必要とする故に HTML CSS は平行してコーディングされるべきだというひともいるかもしれないけれど、それは違う。
インタラクションは意味の高度な表現であるから、基となる意味は複雑な構造をもたない方が汎用性が高まる。
例えば自然言語（日本語等）は単語や接続詞というシンプルな要素によって構成されている。だからこそ、それらを基礎としたより複雑で豊かな表現が可能となっている。
仮にこれが単語ではなく文が一つの意味をもつ構造を持っていた場合、意味毎に違う文を用意し、新たな概念が産まれる度に新たな文を用意しなければならないとしたら、言葉という媒体はとうの昔に崩壊していた。
インタラクションが静的で、かつそれ自体がコンテンツの表現よりも優先され、二度と変わらないものであるならそれでも良いのかもしれないけれど、そんなことはあり得ない。
できればデータレベルまで還元しておきたいけれど、文書である以上、それは不可能な場会もあるかもしれない。
しかし、ひとに読まれてこその文書なので、文書としての表現はデータとしての表現に優先する。だからこそ構造と意味の分離という方法が可能になっているんじゃあなかろうか。データとしてただ保存しておきたいのならデータベースに入れておけばいい。
つまり HTML はひとへ向けての表現と、それを解釈し、操作し、利用するプログラムやスクリプトへの表現という二重の意味表現を必要とする。
それら二重の表現を加味しつつ、ある部分で折り合いをつけていく行為が HTML のマークアップになる。
ふたつの対象とふたつの意味。それらは並行的に確認され、最適化される必要があるに相違ない。
確認する対象がふたつあるのだから、ビュアーはふたついる。語彙は共通のものを使用するべきで、だとしたら語彙の辞書もついておいたほうが都合が良い。
そんなわけでツールのかたちが見えてきた。視覚効果の表現は別のプロセスになるが、それも統合され、かつ分離されているのが便利だ。
そろそろプロトタイプを作成したい。もうブラウザって Microdata DOM API って実装しているのかしら、してないと面倒だけど。