北海道にもWeb標準が普及したのか、私がMTやWPを扱っているからか、最近は会社を通したコーディング案件を扱うことが多くなりました。

静的なウェブサイトの場合、大抵はコーディングの時点で中に入る文章が確定していますが、私の場合ブログやレンタルカートや CMSがベースなので、通常テキスト部分に何を書きこまれるのか予想がつきません。
この点を踏まえて、どんな感じで気を付けているのかご紹介します。
熟練のコーダーさんには、今更な内容も多いですが…^^;

↓このようなサイトのコーディングをしたとして、以降の話を進めます。

coding01

あ、これオリジナルです。クライアントさんの原画使ったら拳で殴られます。
※写真素材:素材辞典フォトバイブル20000(ロイヤリティーフリーです)

右に画像があるときはwidthかpaddingを明示する

coding02

先程のサイトは、ロゴの下のサイト説明文が余白内に一行で納まっています。

この場合、普通にロゴと説明文の間にmarginを指定すればいいのですが、もしここに長い文言を書き込まれた場合、右の女性のヘッダ画像に文字がかぶってしまいます。

静的なサイトだったとしても、クライアント側からの変更指示はよくあることです。
なので、はじめからこの部分にwidthか、右paddingを明示しておきます。

できるだけ縦の伸びに対応する

前項のヘッダに関連して、ブラウザの文字サイズ変更で、サイト説明文を猛烈に大きな文字にしても、崩れず読めるようにコーディングをします。

これはデザインの影響を受けるので、どんなサイトでもできるわけではないのですが、サンプルだと下の画像のように、女性の画像をbackground-positionで下寄せに、かつロゴを透過gifかpngにすれば崩れず表示できます。

coding03

エントリー枠の最後を必ずclearする

ブログやCMSの場合、本文内に更新担当者が画像を貼ることができます。
このとき「左右の配置」も指定できるのですが、
画像の高さより本文の行数が少なかった場合を想定しておかないと、後続する要素(この場合次の記事かページナビゲーション)がfloatに巻き込まれ、実にアクロバティックなページになります。

coding04

この対策として、エントリー内にフッタ要素があればclear:bothを指定してfloatを終了させるか、本文枠をdivで包括してclearfixを指定しておきます。

.entry-body {
height: 100%;
}
.entry-body:after {
content: "."; display: block; clear: both; height: 0px; visibility: hidden; font-size: 1px;
}

「そんなの当たり前じゃん」と突っ込む人もいるかと思いますが、
これに対応していないテンプレート・テーマ・スキンは、レンタルブログの公式テーマなんかでも結構多いです><

本文枠に背景画像があるときはmin-heightを指定する

前の画像を見て、気付かれたでしょうか。
背景の化粧瓶の写真が欠けています。

coding05

本文枠の背景にこのような背景画像があるときは、例え文章が一行しか入らなくても、背景画像の高さ分を最低確保しておく必要があります。
この場合、私はmin-heightで対応しています。

.entry-body {
height: auto !important; /* for Modern Browser */
height: 155px; /* for IE */
min-height: 155px; /* for Modern Browser */
}

本文のline-heightの値に単位を付けない

line-heightの記述方法はいろいろありますが、このときに「150%」や「1.5em」とすると、標準の文字サイズを基準に行の高さが指定されます。
これだと、途中でfontやspanで文字サイズを大きくしたときに、行の上が詰まってしまいます。

coding06

ここで、line-heightに単位を付けずに数値だけにすると
行内の各々のインライン要素を基準に行の高さが指定され(この辺りのCSS仕様にはあまり詳しくないのですが…)、文字を大きくした個所には少し多めの行間が自動で入ります。

table要素をリセットしない

テーブルはブラウザ間で微妙にレンダリングが異なります。
なので、コーディングの最初にborder-collapseやborder-spacingを指定することもあるのですが、ブログやCMSを扱うときは、table関連の要素には直接スタイル指定を行わないようにしています。

更新担当者がCSSレイアウトに習熟しているとは限らないからです。
というより、これまでの経験では担当者の人はほぼ100%、テーブルで表を書いたり段組みをしたりします。

このときにborder-collapse:collapseとしていると、table要素のcellspacing属性が有効になりません。
どうせ、コーディングをする私は、レイアウトにtableを使うことはほとんどないですし…
ここは「顧客満足度」重視で^^;

ただ、このままでは表を書くのが大変です。
なので、更新担当者が表を多用する可能性がある場合は、以下のようにCSSを組んでおき、

.entry-body table.hyo {
margin: 1em 0 2em;
border-collapse: collapse;
border-spacing: 0px;
border-top: 1px solid #CCCCCC;
border-left: 1px solid #CCCCCC;
}

.entry-body table.hyo th {
padding: 7px;
text-align: center;
line-height: 1.2;
border-bottom: 1px solid #CCCCCC;
border-right: 1px solid #CCCCCC;
background-color: #EEEEEE;
}

.entry-body table.hyo td {
padding: 7px;
text-align: center;
line-height: 1.4;
border-bottom: 1px solid #CCCCCC;
border-right: 1px solid #CCCCCC;
}

「<table class="hyo">と書くと、サイトに合わせた表組みが自動でできますよ」
とメールやPDFマニュアルなどでお知らせしたりします。


コーディングは、そのサイトのデザインや、どのように納品するかで千差万別です。
個人の方と一対一でお仕事をするときと、制作会社を通してコーディングのお仕事をもらうときでも考えることが違います。

もちろん、完璧なコーディングが理想ではありますが、最後にサイトを手にするのはあくまでお客様、ということは、念頭に置くようにしています。

この記事を書いた人

うぇびん

愛知県豊橋市に住んでいる、荒ぶるウェブおばさん。WordPressをはじめとした各種CMSを研究するのが好き。札幌のIT企業のビットスター株式会社に所属しています。