W3J.org

HTML+CSSなワークフロー

第二章で、実際にCSSでデザインしていく道のりをたどってみたわけですが、本音をいうと、これって理想的な工程に近かったりします。

CSSによる実装を施すより前に、コンテンツがすべてそろっていなければなりません。また、そのそろっているコンテンツのマークアップもすべて済んでいる必要がありますね。サイト全体のコンテンツにおいてマークアップが済んでいることで、構造の統一化をはかったり、法則性を見出したりできるからです。それに、最終的なデザインをどのようにするかの検討も終わっている必要があります。デザイナーによってデザインがあがっている状態より一歩先の段階です。つまり、そのデザインがCSSでどのように実現するかの検討も済んでいるという状態のことです。サイトマップやコンテンツマップといった、サイトの構成定義にしても、やはりきちんと終わってなければなりません。ページ間で共通的に利用されるナビゲーションエリアの内容などは、マークアップ済みコンテンツには含まれていない場合が考えられますので、定義されている構成にしたがって、各ページを最終的なものに近づけるべく、要素を継ぎ足していく作業も必要になってくるわけです。

中でも、コンテンツがすべてそろっているというのは、難しいことが多いのではないでしょうか。ざっくりと大まかなコンテンツはあるだとか、この辺は全部あたりのデータになっているだとか、そういうときは、きちんとしたマークアップができませんので、CSSの設計が遅々として進まないということが考えられます。ある程度のめどをつけて進めることはもちろんできるのですが、予想していなかった要素が発生した場合など、手戻りが大きな負担となることがあるでしょう。最初から設計しなおすとしたら、それが何度もあるかもしれませんし、つぎはぎの設計で進めることも出来ますが、それはそれでいつ破綻するかと心中はびくびくしているかもしれませんね。

テーブルレイアウトを前提としたサイト制作と、まったく同じワークフローで進めると、こういったことに陥りやすいものと思われます。実装手順が違うのだから、特定のタスクの前に終わらせておかなければならないタスクというのも、また違うわけなのです。

といっても、なんか凄いワークフローの秘策があるわけではないのですが。ようするに、コンテンツをとにかくすべて用意すること、次にマークアップとデザインを並行して進め、デザインの実装について検討したあとで、CSSによるデザインに入る、というわけです。最後にあらゆるブラウザでの表示検証というのがありますが、検証にかかるコストは、テーブルレイアウトよりも圧倒的に多く必要になるでしょう。しかし検証に多くの時間と労力を費やすことは、結果として品質の高いものの提供につながりますので、ぜひとも実践していただきたい感じです。

本文のほうでも書きましたが、マークアップする人たちだけのフロー改善であるとかでは、HTML+CSSなサイト制作はできません。プロジェクトのもっと早い段階から（可能であれば営業であるとか提案であるとかの段階から）、HTML+CSSなサイト制作の手法について、クライアントとよく検討しておくことが大事です。Netscape4.xを愛用しているクライアントの担当者から、最後の最後になって「やっぱりNetscape4.xでも同じように見えるようにして欲しいなあ」などといわれてしまうという、恐ろしい事態にならないようにしたいものです（これは実際にあった話ですというか、わりと往々にしてある話だとも思いますが）。