プロが実践するモダン CSS の書き方入門テクニック20選まとめ - PhotoshopVIP
1. 縦方向のマージン幅
他のプロパティとは異なり、縦方向のマージン幅はうまく効きません。
「うまく効かない」ではなく「相殺される」「重複する」と訳すべきでしょうね。
横方向のマージンは単純に足していけばよい一方、縦方向のマージンは相殺（重複）されるのが仕様です。
この特性が余白に関して想定していない問題を発生させることはよくあります。その代表的な例を2つ紹介します。
親要素にマージン・パディング・ボーダーがなく、子要素にマージンが設定されている場合、子要素のマージンが親要素のマージンに見える
例えば、
<header><h1>タイトル</h1></header>
というコードで、headerのmargin-top、padding-top、border-topが0で、h1にmargin-topがある場合、headerの上にh1のマージンが設けられます。
ここでheaderに背景色を設定していると、headerの上に白い余白が発生します。
「なんだこの余白？」と思ってデバッグしようとするとheader内にあるすべての要素のmargin-topの設定を確認しなければならず、面倒くさいことになります。
ボックス要素が入れ子になっているときに、縦方向に想定以上の余白が発生する
親要素にpadding-top, border-topがない場合、親要素のmargin-topと子要素のmargin-topは相殺されます。
一方、親要素にpadding-topまたはborder-topがある場合、子要素のmargin-topは、親要素のcontentから計算されます。その結果、親要素のmargin-topと子要素のmargin-topは相殺されなくなります。
この時、親要素に背景やborder-topがない場合、子要素の上の余白が妙に広く見えることになります。
margin-topを原則0にして、margin-bottomで縦方向のマージンを制御する方法は、これらの問題の回避に有効です。
2. レイアウトに Flexbox
日本では古いIEがしぶとく生き残る傾向があるので、Flexboxの活用はもうしばらく先のことになりますね。
jQueryライブラリのmatchHeight.jsを使うことで、floatを使いながらもカラムの高さをそろえることができます。
また、横方向の等幅分割を実現する際には、Flexboxよりもdisplay: table; table-layout: fixed;を使う方がブラウザ間の差異をなくすことができます。
新しいプロパティを活用するのはウェブデザインの楽しみの一つですが、安定した「枯れた」テクニックを活用するのもプロに求められる資質ではないかと思います。
3. CSS リセット, 4. Border-box をすべてに適用
原則的に既存のライブラリを使うべきです。元記事では全称セレクタを使ったやり方が紹介されていますが、これは基本的にバッドノウハウです。（言い切っていいのか？）
全称セレクタを使ってよいのは box-sizing: border-box; くらいで、他のプロパティを全称セレクタでリセットするのは継承が失われる副作用の方が強いので避けた方がよいです。
5. イメージファイルは背景に適用するべきではない
なぜimg要素の代わりにbackground-imageを使ってはいけないのか。
理由の筆頭は、「アクセシブルではないから」です。背景画像にはalt属性を付けることができません。装飾以外の機能を持たない画像ならともかく、メインコンテンツの一つとして画像があるのなら、このようなテクニックの採用は即却下すべきです。
アクセシブルではないサイトは、SEOの面で不利になります。
また、この方法は空divというあまり褒められないコードが増えるため、この点でも評価は下がるでしょう。
これらの問題を解決するために、背景画像を用意したdiv要素内にalt属性にあたる解説文を付けるという方法もあるかもしれません。しかしその文字は画像の上に被って表示されます。alt属性の代替とするには text-indent: -120%; overflow: hidden; なんて方法を使わなければなりません。（今はどうかわかりませんが）MacOSのChromeだとこれでも1文字だけは表示されます。そしてGoogleの検索エンジンは隠しテキストと判断してやはりサイトの評価を下げるでしょう。
元記事にはこの点への言及があるものの、翻訳記事の方でこの重要なポイントをばっさり削除してしまっています。
その結果、まったく褒められない行為を推奨する記事と化してしまったことは残念なことです。
レスポンシブデザインに対応するなら、次の方法が最も簡便に行えます。
画像にはheight: auto; を活用する。
例えば、画像の幅をウィンドウ幅の50%にして、縦横比を元画像と同じにしたいときはこうします。
img {
width: 50%;
height: auto;
}
これだけです。わざわざdivを用意して、それぞれに高さ、幅を付けて、背景画像を用意して、なんて面倒なことは不要です。
十分なサイズ（表示したいサイズの2〜3倍の解像度）の画像を用意すれば、スマートフォンのような高精細ディスプレイでもきれいに表示されます。
十分なサイズの画像が用意できず、width: 50%; では画像が引き延ばされてぼやけてしまう場合は次のようにします。
img {
width: auto;
max-width: 50%;
height: auto;
}
これで画像は元サイズ以上に引き延ばされることはなくなります。
6. リストテーブル
まあ、border-collapse: collapse; は基本ですね。ここではレスポンシブ対応について補足します。
テーブル要素のレスポンシブ対応
ちょっと気になるのは、「リスト用テーブル」ってところでしょうか。リスト目的ならdl要素を使うのがセマンティックにできると思います。
もっとも、dlは枠線のコントロールなどが少し面倒になるので、十分な時間がない場合はtableの利用もありうるでしょう。タイトル部にthを、説明部にはtdを使えばそれなりに意味は通ります。
さて、タイトルと説明、というような2列しかないテーブルをレスポンシブデザインに対応させるときには、displayプロパティを活用します。
ブレイクポイントを通過したところで、th, td 要素に display: block;を適用すると、横並びの表組を崩して縦に並べることができます。
リスト用ではなく、本来の意味での表組で、横並びを崩すことができない場合は、tableをdivで囲み、
div {
width: 100%;
overflow-x: scroll;
}
table {
width: 100%;
min-width: 640px;
}
のようにして、一定の幅を下回ると（上記の場合640px）表のみ横スクロールが発生するようにします。
8. クラス名に「串刺しスタイル」を利用
WordPressのCSSコーディング基準はそうなってますが、それが絶対ということはありません。
私もハイフンつなぎを好んで使っていますが、みんな好きにすればいいんじゃないですかね。MindeBEMdingなんてハイフン2個とアンダースコア2個なんて気持ち悪い感じ（いまだに慣れません）でやってますし。
とはいえ、アンダースコアは、ハイフンに比べて２つの点で劣ります。
一つ目は、アンダースコアはハイフンに比べて目立たず、存在を見つけにくいという点。
二つ目は、タイプ時にShiftキーとの組み合わせが必要で、かつキーボードのホームポジションから最も遠いためタイプミスを犯しやすいことです。
そのほか、相性面での問題として、WordPressの場合、コーディング基準に違反することになります。また、Bootstrapなどの主要なフレームワークの多くはハイフンつなぎなので、それらと組み合わせると命名に規則性がなくなり、メンテナンス性が悪化します。この相性問題はキャメルケースを使った場合も同様です。
9. 繰り返しを避けよう。
補足は必要ないですね。
特にフォント回り（font-family, font-size, line-heigt）に関してはhtmlかbodyで初期値を設定します。
これを全称セレクタ（*）に適用してしまった場合は地獄を見ることになります。
その他
10〜20は大きく補足するようなことはないかなと。
14. 大文字
CSSで制御すべきなのでしょうか。状況次第のような気がします。
元サイトでは「賛同できない。セマンティックにやるなら<em>を使うべき。」とのコメントが寄せられていますね。
15. rem
remは、IE9,10ではショートハンドでは使えないという制限があります。
元記事において
pxはもっとも正確性がありますが、レスポンシブデザインでは拡大縮小スケールに対応していません。
とあるのですが「拡大縮小スケールに対応していない」というのがよく分からないですね。普通にctrl+マウスホイールでレスポンシブに拡大縮小できるので。
一方、IEではpxで指定した場合、メニューから「文字サイズの変更」を行っても文字サイズが変わらないという問題があります。それゆえアクセシビリティ/ユーザビリティ界隈ではpxの使用を避けるように言われているのですが、メニューから文字サイズの変更を選ぶ人ってどのくらいいるんでしょうね。
HTMLにfont-size: 10px;として、文字サイズをremで指定すると計算しやすくてよいかもしれません。
16. 大きなプロジェクト
Sassは書き方がCSSに近いため、学習コストが低いのが特徴です。まだ試してない人はさっさと導入しましょう。
大きいプロジェクトであれば、Sassの他にコードの可読性を上げるCSSCombの利用も重要だと思います。主要なテキストエディタのほとんどで利用可能です。
18. 圧縮コードの利用
私は圧縮コード（ミニファイ）には否定的な見解を持っています。画像などと異なりもともと大したファイルサイズではないですし、改行コードやスペースを削除したところで大幅にファイルサイズが減るわけじゃありません。
読み込み時間を改善するのなら、まず読み込むファイルの数を減らすのが先だろうと思います。CSSやjsファイルはなるべく一つにまとめる、CSSで代替できる箇所には画像を使わない、WordPressであればプラグインを入れすぎていないかなど、検証すべきところは多々あります。
本気で取り組むならgzip圧縮やCDNの活用の方がはるかに効果的でしょう。
また、CSSフレームワークではBootstrapが人気ですが、これは（CSSファイルにしては）巨大で、しかもその機能の7割くらいは使われず無駄になっています。またBootstrapのグリッドシステムはその構造上、HTMLの肥大化を招きやすい問題（グリッド間の余白を作るのに内部にdivを追加する必要があるなど）を抱えています。
読み込み時間を短くしたいのならまずは上記のような無駄をそぎ落とすのが先であって、それらをやったうえで、１バイトでも無駄を削り切りたいときにミニファイは行うべきだろうと思います。
