ワンランク上のHTMLコーディングを行うための18のポイント

Webデザイン , Web制作

HTMLコーディングの初級というと、どの程度のスキルを差すのでしょうか。弊社では、以下のようなことがひとまずできていると、だいたい初級レベルを越え始めた段階かな、という気がしています。

  • ターゲットブラウザで大きな崩れがない。
  • リンク漏れや原稿違いなどのヒューマンエラーの頻度が極めて低い。
  • バリデーター・チェックでエラーが出ない。

逆に、これだけのことができて、なぜまだ初級レベルなのでしょうか。それは、現場では、これだけでは不十分だからです。ブラウザでひとまず正常に表示されるだけでなく、改修に素早く対応できる柔軟性、協業や運用後の更新を楽にするルールの一貫性や簡潔さ、HTMLの概念をきちんと踏まえた正しい構造設計なども、求められてくるからです。

そこでここでは、脱・初級者を目指す方のために、弊社内で行っているHTMLコーディングの、いわゆるエラーということ以外のチェックポイントを、まとめてみました。議論の余地は多々あるかと思いますが、より深く追求するキッカケになれば幸いです。

※HTMLコーディングを始めて数か月くらいの方を想定した内容ですが、ご了承ください。

1. HTML上の記述順と、情報の順番をきちんと合わせる。

HTMLとは、データそのものです。そのため、HTMLに記述される情報の順番は、本来、人が読む文脈の流れとイコールでなければなりません。

例えば、ポジション指定やフロートによって、HTML上の並べ方を無視し、ブラウザ上では問題ないように見せることもできますが、これは本来推奨されません。ワンランク上を目指すには、HTMLのデータ構造の正しさまで配慮してコーディングを行いましょう。

2. タグは、本来の使い方をする。

たまに、ブロック要素には全てdivを使ったり、pやliの本来の使い方を無視して作っているサイトを見かけます。確かにCSSで定義すれば、ブラウザ上では問題なく見せることはできるのですが、HTMLはできる限り、本来の意味を踏襲してコーディングした方がよいでしょう。

例えば、pタグは段落要素だけに使用する、リストはul、ol、dlを使い分ける、表はdlではなくtableタグを使う、などといったことです。

3. bodyタグに、固有のclassを設定しておく。

これは必ずしも、というわけではないですが、弊社では、更新のしやすさ、要望対応などへの柔軟性や拡張性への配慮として、bodyタグにclassを設定しておくことを推奨しています。該当画面特有の追加仕様や例外事項が発生しても、柔軟に対応できるようになります。CMSテンプレートの制約などで実施できないこともありますが、これに限らず、先に起こりえる可能性も見据えた対応も行う、ということも意識したいところです。

bodyタグへの設定例

ホーム画面の場合：<body class=”home”>

会社情報の企業理念の場合：<body class=”companyPhilosophy”>

4. JavaScriptのライブラリは乱用しない。

最近はJavaScriptのライブラリを使わないサイトはほとんどないでしょう。しかし、ちょっとしたことですぐにライブラリに手を出すのはやめた方がいいと考えています。

ライブラリは汎用性を重視するため、そのサイトには必要のないはずの処理が多く含まれています。スペックの低い端末で処理が遅くなったり、他のJavaScriptやブラウザの機能とバッティングしたり、きちんとエラー処理がされないまま配布されていることもあります。

デザインは、できるだけHTMLとCSSの組み合わせで対処し、どうしても難しい場合にのみJavaScriptに頼る、というように考えておきましょう。

5. CSSの値の指定は極力短縮する。

現在の回線状況では、テキストの文量が速度に影響することはなくなりました。とはいえ、軽いに越したことはありません。HTMLコーディングをするなら、見やすさなどには配慮しつつも、できるかぎり軽量でシンプルなソースコードを目指すべきでしょう。CSSでは、省略した記述も可能ですので、こういった記述方法で統一し、シンプルで見やすいソースコードを心がけましょう。

  • ゼロには単位を付けない。（例：0px→0）
  • ゼロ以下の少数にはゼロを省略する。（例：0.1em→.1em）
  • 色の指定が省略できるときは省略する。（例：#FFFFFF→#FFF）

6. ショートハンドを使用し、短いプロパティで定義する。

CSSでは、ショートハンドといって、より簡略に書く記述方法が可能です。ソースコードの軽量化、シンプル化という意味でも、このショートハンドを活用した記述で統一するとよいと思います。

悪い例

padding-top: 0;
padding-right: 10px;
padding-bottom: 20px;
padding-left: 10px;

良い例

padding: 0 10px 20px;

7. タイプセレクタはできるだけ省略する。

これもより簡潔に、軽量に、という方針の一貫ですが、classとセットで指定するタイプセレクタは記述せず、classのみにすると、よりシンプルな記述になります。5、6項もそうですが、実際このあたりは書き方の好みの問題ではあります。しかしそれ故に、ファイル内で表記方法がブレやすいポイントでもあるため、少なくとも、プロジェクト内ではどういう方針で行くか、というのはあらかじめ決めておく必要があるでしょう。

例：li.icoA→.icoA

8. プロパティは常に同じ順序で記述する。

CSSでは、プロパティを記載する順番は関係なく処理が実行されます。ただ、都度思いつきで設定していると、他人が見たときに分かりにくく、また自分自身も後から見たときに、見落としたりする可能性も出てきます。そういったことを想定し、プロパティの順番は統一しておくようにしましょう。

順番の例：

  1. 位置情報系＝position, top, right, z-index, display, float等
  2. サイズ＝width, height, padding, margin
  3. 文字系＝font, line-height, letter-spacing, color- text-align等
  4. 背景＝background, border等
  5. その他＝animation, transition等

9. インデント、改行など一定のルールで行なう。

HTMLでもインデントの統一はよくいわれますが、CSSにおいても、見やすく分かりやすいソースコードを目指すために、インデントや改行のルールはできるだけ統一するようにしましょう。インデントには色々な解釈がありますが、大事なのは、統一する、ということです。

主な弊社でのルール：

  • インデントはハードタブ1つで統一する
  • コロン後に半角スペースを入れる
  • ルール毎に1行空ける
  • {の前では改行せず、後では改行する
  • 別々のセレクタとプロパティは改行を入れ複数行で記述する

記述例：

.boxAttention ,
.boxConversion {
　　width: 960px;
　　padding: 20px 0 30px;
　　margin: 0 auto;
}

10. idセレクタの使用は最小限に。

idはページ内の重要要素として指定が優先的に効く反面、1ページ内で1種類しか適応できない、classで上書き指定する場合に優先されない、などの無用な制約が生まれがちです。これも議論が分かれるところだとは思いますが、弊社では、最低限の共通要素（例えば、id=”header”やid=”footer”など）やページ内リンクで必要な個所以外では極力使わない、という方針でいます。

11. 命名ルールは統一する。

idやclassはどのように命名しても問題なく表示されますが、やはり他の人がソースコードを触ったり、あるいは顧客企業のソースコードを見られたときも想定し、命名ルールはできるだけ統一しておいた方がいいでしょう。弊社では、先頭を小文字、次以降の単語の先頭を大文字にし、スペースやハイフンを使わないローワーキャメルケースで統一しています。

例：.Box-attention→.boxAttention

12. 内容を的確に表現したクラス名にする。

classの名前は、それが何のためのclassか、きちんと表現できていた方がベターです。例えば、コンテンツを入れるボックスはbox01などという名前ではなく、ボックスの役割がわかる名前のほうがいいでしょう。同じ労力で実現できるなら、より良い方法を選択する、というのもHTMLコーディングでは必要な感覚です。

例：.box01→.boxAttention

13. 無駄なclassの乱用を避ける。

classを無計画に多用していくと、煩雑なソースコードになり、メンテナンス性も落ちていきます。また、ブログなどでは、いちいちタグにclassを指定しないとキレイに見えないような組み方をしていると、運用に悪影響を与えることもあります。divやspanなどの汎用タグを用いたり、classの継承セレクタを用いて、できるだけ簡潔なソースコードで記述したほうがよいでしょう。

悪い例

div内の個別要素に細かくクラスが指定されている。

<div>
　　<h2 class=”newsTitle”>お客様へのお知らせ</h2>
　　<p class=”newsText”>以下の製品をお求めのお客様にお知らせがあります</p>
　　<ul>
　　　　<li class=”newsList”>T-1000<li>
　　　　<li class=”newsList”>T-1002<li>
　　　　<li class=”newsList”>T-1010<li>
　　　　<li class=”newsList”>T-1011<li>
　　</ul>
</div>

良い例

divにのみクラスを付け、子要素にはクラスは付けていない。

<div class=”newsBox”>
　　<h2>お客様へのお知らせ</h2>
　　<p>以下の製品をお求めのお客様にお知らせがあります</p>
　　<ul>
　　　　<li>T-1000<li>
　　　　<li>T-1002<li>
　　　　<li>T-1010<li>
　　　　<li>T-1011<li>
　　</ul>
</div>

14. 特定プロパティを指定するためだけのclassを記述しない。

特定のプロパティを指定するためだけのcssを設定するのは避けたほうがいいでしょう。ソースコードが煩雑になったり、classの管理が複雑になります。またこれでは、cssをHTMLに直接書かず、わざわざ別ファイルに整理して記述している意味もなくなってしまいます。

悪い例：

各所のマージンを調整するためだけのclass。これを様々な場所に記述するような書き方は避ける。

.marginTopL {
　　margin-top: 30px;
}

15. clearfixのためだけのclassを付与しない。

clearfixはよく使われるテクニックと思いますが、時々、HTML内に大量にclearfixクラスを付与してるようなサイトを時に見かけます。14同様の考えで、ソースコードが煩雑になり、追加や修正、削除などのメンテナンスも面倒になるため、これはできれば避けた方がよいでしょう。clearfixを指定するときは、cssファイル内にclearfix用のプロパティを記述して管理するようにしましょう。

例：

.hogeHoge:after ,
.hogeHogeHoge:after {
　　clear: both;
　　height: 0;
　　visibility: hidden;
　　font-size: 0;
　　display: block;
　　content: ” “;
}


* html .hogeHoge ,
* html .hogeHogeHoge {
　　zoom: 1;
}


*:first-child+html .hogeHoge ,
*:first-child+html .hogeHogeHoge {
　　zoom: 1;
}

16. 画像ファイルのファイル名は用途を分かりやすくする。

画像ファイルのファイル名は、リンク先さえ間違えてなければ、自由な名前にしても大きな問題は発生しません。ただ、変更が発生した際、あるいは別の人が運用に関わることを想定し、ファイル名からどういうファイルなのか、ある程度想像できておいた方が、一つ一つの画像をプレビューして探し出すような余計な作業が軽減され、親切な作りであるといえます。例えば、弊社では、以下のように、画像の冒頭にその画像の用途を入れる命名ルールにすることで、こういったことに対応しています。

  • h1画像：h1_xxx.jpg
  • h2画像：h2_xxx.jpg
  • 背景画像：bg_xxx.jpg
  • 線の画像：line_xxx.jpg
  • ボタン画像：btn_xxx.jpg
  • アイコン画像：icon_xxx.jpg
  • 単なる画像：img_xxx.jpg

また、名前を付けるときは、画像とは関係ない番号は避け、ユニークな名前をできるだけ付けるようにします。

例：

コンテンツ下部にCTAとして設置されるお問い合わせボタンなら

btn_contact03.jpg → btn_contact_cta_l.jpg

17. 画像のファイルサイズはできるだけ軽く。

近年はファイルサイズに神経質になる必要がなくなったためか、画像サイズに無頓着なのでは、というケースを以前より見かけるようになりました。例えば、パターン化できる背景や、画質が重要でない画像に、何百KBあるいは1MB以上の画像サイズを割り当てているような例です。いくら回線が速くなったとはいえ、画像は軽いに越したことはありません。特に200KBを越えるような画像は、そのサイズの必然性があるか、今一度チェックした方がよいかもしれません。

また、ファイル形式によって画像サイズは大きく変わります。jpeg、gif、pngをうまく使い分けて、美観を損ねず、できるだけ軽量に仕上げるという、絶妙なバランスを常に意識するようにしましょう。

jpeg

圧縮率でサイズがかなり変わる。写真など、色数や諧調が多い画像に向いている。

gif

うまく使えば非常に軽量で美しい画像が作れる。塗りのシンプルなイラストや図形など、色数が少なく複雑に色が混在していない画像に向いている。

png

アルファ値を持たせて透過させることができる。トレンドとなってる表現を取り込む上で避けては通れないが、小さな画像でもサイズが大きくなる傾向があるので、利用には注意が必要。

18. 不要ファイルは残さない。

最終納品時には、不要なファイルもきちんと削除して、納品するようにしましょう。修正などで不要になった画像などはもちろんですが、システム的に生成されるような不可視ファイルなどがデータ内に含まれてしまうこともあります。また、不要ファイルを一括削除するツールもありますので、目視ではなく、できるだけ機械的に対応しましょう。

まとめ

弊社内ではこれ以外にも、ケースバイケースで細かなルールが発生することがありますし、作業効率を考え、この通りにしないこともあります。実際の現場では、様々な要因でルールの徹底が難しくなることもあるでしょう。

しかし、どのような場合でも意識しておきたいのは、ただブラウザで見えればいい、という考えではなく、ソースコードを触る他の人、ソースコードを公開することになる顧客企業、たまたまソースコードを見たユーザなどへの、一貫した「気遣い」もできるだけ実装する、という感覚です。

本記事で、HTMLコーディングをもう一段深く考え、初級レベルを抜け出すことができるキッカケになれれば幸いです。