Trans

NPOやソーシャルビジネスの創業・経営・マネジメント

HTML×CSSのプレビュー型とアーキテクト型コーディングフロー

CSSにはプレビュー型とアーキテクト型コーディングフローというのがあり、今後はアーキテクト型コーディングが主流になるのでは!というアイディアを思いつき、実際にコーディングしてみたら。・・・挫折しました。ただ、こういう考え方もありなのかなと思い、書いておきます。

プレビュー型コーディング

先に申し上げておきますが、このプレビュー型とアーキテクト型コーディングフローとはどこかのCSSハッカーの言葉ではなく、僕が便宜上名付けただけです。というわけで知った顔して誰かに話しても、全く通じないこと請け合いなので気をつけてください。
さて、ここでいうプレビュー型コーディングとはこんなコーディングフローのことを意味しています。

  1. HTMLをコーディング
  2. PhotoshopやFireworksの画像をスライス
  3. HTMLで書いたid属性やclass属性を軸にCSSをコーディング

多少の前後はあるにせよ、このフローでコーディングすると、コードはこんな感じになると思います。

<ul id="navi">
	<li><a href="hogehoge1">ナビ1</a>
	<li><a href="hogehoge2">ナビ2</a>
</ul>

<div id="main">
	<h2>ここにタイトル</h2>
</div>
ul#navi {
	margin-bottom: 30px;
}

ul#navi li {
	float: left;
}

div#main {
	margin-bottom: 30px;
	padding-left: 15px;
}

div#main h2 {
	padding-left: 15px;
	color: #FFCC00;
}

プレビュー型コーディングと名付けたのは、オーサリングツールやブラウザ等でプレビューしながらコーディングするからです。要は目視で確認しながら、デザインの各パーツを配置していくということになります。

プレビュー型コーディングの問題点

個人的にこのプレビュー型コーディングの問題点になりそうなものを上げておきます。

  • margin-bottom: 30px;やpadding-left: 15px;などコードが重複する可能性がある。プレビューしながらコーディングすることが前提なので、CSSを設計せずにいきなりコーディングを開始するため。
  • デフォルトのリセットやコンポーネント(もしくはモジュール)CSS、要は使い回し系のCSSと重複する可能性もある。
  • 目視をベースにするため、細かな余白や行間等がデザイナーによって指示されず、コーダーがコーディング中に判断するしかなくなる。

というあたりかなと思います。

アーキテクト型コーディング

アーキテクト型コーディングとはこんなコーディングフローを指し示します。ちなみに、アーキテクトとは設計という意味で使っています。

  1. HTMLをid属性のみでコーディング
  2. PhotoshopやFireworksで余白やカラー等の値の抽出してから、画像をスライス
  3. 抽出した値をCSSに書き込む
  4. 必要なclass属性をHTMLに書き加える
  5. その他のCSSをコーディング

意味分からないですね(苦笑)例えば、こんな感じです。まず、始めにHTMLをコーディング。

<ul id="navi">
	<li><a href="hogehoge1">ナビ1</a>
	<li><a href="hogehoge2">ナビ2</a>
</ul>

<div id="main">
	<h2>ここにタイトル</h2>
</div>

次にPhotoshopやFireworksで余白やカラー等の値を抽出し、画像をスライスします。すると、デザインはmargin-bottom: 30px;やpadding-left: 15px;は繰り返し使われていることが分かります。そこで、CSSにこんなコーディング。

.ma-1 {
	margin-bottom: 30px;
}

.pa-1 {
	padding-left: 15px;
}

そして、この値をHTMLにclass属性を付け加えて、付与します。

<ul id="navi" class="ma-1">
	<li><a href="hogehoge1">ナビ1</a>
	<li><a href="hogehoge2">ナビ2</a>
</ul>

<div id="main" class="ma-1 pa-1">
	<h2 class="pa-1">ここにタイトル</h2>
</div>

最後に、CSSをもう少し追加します。

ul#navi li {
	float: left;
}

div#main h2 {
	color: #FFCC00;
}

これで、HTMLもCSSも重複せずにきれいなんじゃないの!と思ったのです。いきなりコーディングから始めるのではなく、最初に十分にHTMLやCSSをどのように構造化すればよいのかを考えてから設計するということです。

よりよいコーディングフローを求めて

とここまで書いて、実際のサイト制作の際に使ってみたのですが、正直すごく面倒くさい。はじめにPhotoshopやFireworksで余白やカラーの値を抽出するまではよいのですが、それを1つずつ宣言ブロックに書き換えていくのは思ったより時間がかかります(もしかすると大規模サイトでは有効かもしれませんが)。それに、class属性が構造と表現を分離しているとは言えません。
けれど、PHPJavaScriptなどのプログラミングをする人間からすると、設計もアルゴリズムも考えずにいきなりコーディングするというのはあり得ないとは思います(プログラミングはまだまだ勉強中ですが)。一方、HTMLはマークアップ言語だから、そういうものなのかなとも思ったり。
はたまた、個人的にはWordPressのセマンティックなテーマと呼ばれるSandboxのようなコードの吐き方(body、エントリー、コメントのclass属性にスクリプトで任意の値を自動的に与える)はアリだと思っています。しかし、それを手動でやろうとするとこんなことになってしまいました。
もしかすると全面的にこれを用いずに、部分的に用いるとか(グリッドシステムなら余白等はかなり重複します)。いや、コーディングしながら重複する部分はまとめていって、コードの可読性を上げるとか。でもそれも時間ばかりかかって面倒だよなー。そういうことをつらつらと考えていました。
すいません、特に結論はないです。