1. まだ間に合う「CSS設計」ことはじめ。
CSSの闇に飲み込まれないための考え方。
2016.4.12 @WP-D Week Day 2
2016.4.12 @WP-D Week Day 2 1

2. whoami
じこしょうかい
2016.4.12 @WP-D Week Day 2 2

3. Toro_Unit
占部 紘 (うらべ ひろし)
Frontend Engineer / Web Designer
Github: @torounit
Twitter: @Toro_Unit
Facebook: fb.me/torounit
WEB Site: https://torounit.com
2016.4.12 @WP-D Week Day 2 3

4. 長野県松本市ってところで、
フリーランスしてます。
でも群馬県出身
2016.4.12 @WP-D Week Day 2 4

5. Profile
• WordPress な人です。パーマリンクのプラグイン作ったり、
コアコントリビューターになったり、いろいろやってます。
• CSS絡みでは、使いやすいWordPressのためのCSSのつくり
かた とかで登壇したり、Basis というCSSフレームワークに
プルリクを送りつけたりしてました。
2016.4.12 @WP-D Week Day 2 5

6. では本題。
2016.4.12 @WP-D Week Day 2 6

7. 皆さん、
こんな経験はありませんか？
2016.4.12 @WP-D Week Day 2 7

8. • 1年以上前に納品した案件の修正依頼。
• 誰が書いたのかも良く解らない引き継ぎ案件。
• 1万行を余裕で超えてるCSS。
• ほとんどは、コピペコードの狂喜乱舞。
• しかも細かいところが少しずつ違ってる。
2016.4.12 @WP-D Week Day 2 8

9. 「既存のCSS？誰が読むか！」
2016.4.12 @WP-D Week Day 2 9

10. 結果
2016.4.12 @WP-D Week Day 2 10

11. 増殖する の、「fix.css」, 「append.css」,
「custom.css」, etc...
2016.4.12 @WP-D Week Day 2 11

12. そして生まれる important! の腐海。
もはや誰も触れない CSS の誕生。
2016.4.12 @WP-D Week Day 2 12

13. 2016.4.12 @WP-D Week Day 2 13

14. 別にこれって、ここ最近の話じゃ無いよね ...
2016.4.12 @WP-D Week Day 2 14

15. 人類は「CSSは難しい！」ということにいい加減に気づくべき。
2016.4.12 @WP-D Week Day 2 15

16. そんな昨今ですが、
マルチデバイス対応、レスポンシブだ
とかで、ますます難しくなるCSS
2016.4.12 @WP-D Week Day 2 16

17. • IEの闇からいい加減抜け出したと思ったのに…
• だれだよ!!! HTML/CSSは簡単だとか言った奴は!!!
2016.4.12 @WP-D Week Day 2 17

18. はい。
2016.4.12 @WP-D Week Day 2 18

19. Q. では、人類はどうやってCSSと立ち
向かえば良いのか？
2016.4.12 @WP-D Week Day 2 19

20. A. カオス化しないようにCSSを書く!
2016.4.12 @WP-D Week Day 2 20

21. カオス化しないようなCSS
• ページ・要素の追加が簡単にできること。ある程度 CSS 書か
なくても出来るようにすること。そもそもCSSを追記しなけ
れば腐海化しない。
• 保守・デザイン変更が簡単にできること。どこをいじれば良
いのかが、わかりやすいこと。不要な CSS が残りづらい、影
響し辛いようにすれば、CSSの上書き地獄、important 地獄
は防げる。
2016.4.12 @WP-D Week Day 2 21

22. • 人間にとって読みやすいこと。そもそも、人間が読む気にな
らない or 読めない CSS が腐海化しないわけがない。という
か既に腐海。
2016.4.12 @WP-D Week Day 2 22

23. どうやって？
2016.4.12 @WP-D Week Day 2 23

24. CSS で開発する上での戦略を立てる。
2016.4.12 @WP-D Week Day 2 24

25. この戦略 = 「CSS設計」
2016.4.12 @WP-D Week Day 2 25

26. Google のエンジニアの Philip Walton 氏がこの件について書い
た記事がこちら。CSS Architecture — Philip Walton
• 日本語版：CSS Architecture
2016.4.12 @WP-D Week Day 2 26

27. Philip Walton 氏の言う良い CSS の条件とは。
• 予測しやすい (PIEの原則)
• 再利用しやすい (DRY原則)
• 保守しやすい / 拡張しやすい (オープン・クローズドの原則)
2016.4.12 @WP-D Week Day 2 27

28. そのために、実践していること。
2016.4.12 @WP-D Week Day 2 28

29. 1. ちゃんと OOCSS やる
2016.4.12 @WP-D Week Day 2 29

30. OOCSSの２大原則
1. 構造と見た目を分離。
2. コンテナとコンテンツの分離。
2016.4.12 @WP-D Week Day 2 30

31. 構造と見た目の分離
2016.4.12 @WP-D Week Day 2 31

32. .submit-btn {
display: inline-block;
padding: 10px;
color: #FFF;
background: #66C;
}
.link-btn {
display: inline-block;
padding: 10px;
color: #333;
background: #C90;
}
2016.4.12 @WP-D Week Day 2 32

33. こうしよう
2016.4.12 @WP-D Week Day 2 33

34. /*ボタンの構造*/
.btn {
display: inline-block;
padding: 10px;
}
/*ボタンの見た目*/
.btn-submit {
color: #FFF;
background: #66C;
}
.btn-link {
color: #333;
background: #C90;
}
2016.4.12 @WP-D Week Day 2 34

35. 構造と見た目の分離するメリット
1.コードの重複が避けられる。保守性が上がる。
2.拡張がとても用意になる。
例
• Bootstrap の Button
2016.4.12 @WP-D Week Day 2 35

36. コンテナとコンテンツの分離
<aside class="sidebar">
<div>
<img class="avatar" />
</div>
</aside>
.sidebar .avatar {
width: 200px;
border: 5px solid #FFF;
box-shadow: 0 2px 3px #000;
}
2016.4.12 @WP-D Week Day 2 36

37. こうしよう
2016.4.12 @WP-D Week Day 2 37

38. <aside class="sidebar">
<div class="sidebar-widget">
<img class="avatar" />
</div>
</aside>
.sidebar-widget { /** コンテナ **/
width: 200px;
}
.avatar { /** コンテンツ **/
width: 100%;
border: 5px solid #FFF;
box-shadow: 0 2px 3px #000;
}
2016.4.12 @WP-D Week Day 2 38

39. コンテナとコンテンツの分離のメリット
1. 場所、コンテキストに依存しないコードが増える。
2. 再利用しやすい！
3. サイドバーのウィジェットに、.widget { width: 200px }
みたいな CSS とかやりがちですけど、フッターでも使いた
い...けど横幅していが邪魔…なんてのは良くある話。
2016.4.12 @WP-D Week Day 2 39

40. OOCSSの例
• Bootstrap
• Foundation
2016.4.12 @WP-D Week Day 2 40

41. OOCSSはすべての基礎なので、これは
本当にしっかり押さえよう。
2016.4.12 @WP-D Week Day 2 41

42. 詳しくは緑本を読もう
2016.4.12 @WP-D Week Day 2 42

43. 2.仕事のやり方等
2016.4.12 @WP-D Week Day 2 43

44. ページ、デザインカンプごとに CSS を作らな
い。コンポーネント指向な CSS を。
• これをやるとだいたい、新規ページ追加のたびに CSS を追記
する事態が起こる。
• .page-privacy みたいなクラスをbodyを書かないとだめな
CSSとか、他のページで使いたいとき、どうするの？
• 汎用性のあるパーツを組み合わせて、HTML を組んでいける
ものを目指すべし。
2016.4.12 @WP-D Week Day 2 44

45. CSSは整理する。
1. リセット・normalize
2. ベースのHTML要素へのCSS
3. レイアウト、パーツなどのコンポーネントへのCSS
という順に詳細度の低い順で書いていく。
2016.4.12 @WP-D Week Day 2 45

46. HTML、コンテンツに依存しない。
• HTML・コンテンツが変わっても変わらないようにCSSは設
計する。
• クラス名等も、コンテンツに依存するものではなく、機能に
対して命名する。ニュースエントリーに対して、.news-entry
と命名して、その後それを店舗紹介でも使うことになった
り。。。（実話）
2016.4.12 @WP-D Week Day 2 46

47. 一つのコンポーネントでいろいろやり過ぎない。
• サイドバーのウィジェットに、.widget { width: 200px }
みたいな CSS とかやりがちですけど、フッターでも使いた
い...けど横幅していが邪魔…なんてのは良くある話。
• 要素と、レイアウトのための CSS はしっかり分割。絶対値で
サイズや場所を指定しているものは要注意。
• コンテナーとコンテンツの分離はしっかり。
2016.4.12 @WP-D Week Day 2 47

48. セレクターの強さは可能な限り弱く。
• ID セレクタは使わない！セレクターが無駄に強くなって !
important 地獄を引き起こす。また、IDセレクタには、ペー
ジ内リンクなどの役割もあるのでコンテンツに依存しがち。
• .entry-body h1 みたいなこともやりがちですが、こういった
CSSがあったりすると、h1にクラスを当てて...みたいなとき
に CSS が適用されない等のトラブルが。。。
2016.4.12 @WP-D Week Day 2 48

49. 親要素に依存したセレクターは使わない。
• .comment .title, .entry .title 等のセレクターは一見良さそうだ
けど、.title に CSS があたらないなんて保証はないし、.entry
の中に .comment が存在した場合とか。。。.comment-
title, .entry-title 等、親要素に依存しない命名は大事。
• SMACSSとか、BEM等を導入すると楽かも。
2016.4.12 @WP-D Week Day 2 49

50. 機能、コンポーネントごとにファイル分割する
• 一枚の CSS ファイルにゴリゴリ書いていくと、どうしても一
つの機能を実現するための CSSが分散したりしがち。なの
で、機能ごとに CSS ファイルを分割すべし。
• 一つのコンポーネントでいろいろやり過ぎてないか？分割す
べきか？等の指針にもなる。
• 使わないCSSを発見しやすい。
2016.4.12 @WP-D Week Day 2 50

51. 本文などの要素からCSSを書いていく。
• リセットのあとに書く、HTML要素への CSS はそのサイトの
基本のデザイン。これをまずはしっかり実装する。本文欄用
に、.main-contents h2 等の CSS を書くのは確実に CSS を複
雑にする。
2016.4.12 @WP-D Week Day 2 51

52. みんな緑の本読んで、
SMACSSとかFLOCSS
とかやればいいよ!!!
2016.4.12 @WP-D Week Day 2 52

53. 3. 心構え編
2016.4.12 @WP-D Week Day 2 53

54. 強い心を持とう。
• CSSは超ゆるふわ言語。簡単に壊れる。一度設計が破綻する
と、その CSS の設計が信用できなくなる。
• クソコードへの憎しみ、技術者としてのプライドは超重要。
• 割れた窓の法則、ボーイスカウトの規則
2016.4.12 @WP-D Week Day 2 54

55. 安易なコピペコードは麻薬。
• CSS が無駄に長くなって、腐海化する一番の元凶。
• 既存のコンポーネントの拡張で出来ないものかを考えよう。
• コピペしたくなったときは、設計を見直すチャンス。
2016.4.12 @WP-D Week Day 2 55

56. Refactoring！Refactoring！Refactoring！
• CSS を書くときは、デザインがブラウザで再現できた！で終
わりにしない。絶対リファクタリングする！
• 既存のコンポーネントの拡張で出来ること、一つのコンポー
ネントの役割が大きすぎるケースは多分に存在する。
• CSS は放っておくとすぐに複雑怪奇になってしまうので、常
にシンプルな構造になるようにリファクタリングしながら開
発していくこと。
2016.4.12 @WP-D Week Day 2 56

57. ドキュメント大事。
• せめて、ファイル分割のルール、命名規約などはドキュメン
トにする。半年前の設計なんて確実に忘れる。
• オレオレ設計とかどうせ忘れるし変わるので、SMACSSとか
FLOCSSとかちゃんとドキュメントのあるものを使うといろ
いろ楽。
2016.4.12 @WP-D Week Day 2 57

58. リファクタリングもドキュメントも毎
回やれない場合こそ、ちゃんとしたも
のをつくって、使い回そう。
ついでにGithubとかに置いておいてOSSとかにしておくといろいろ幸せになれるかも。
2016.4.12 @WP-D Week Day 2 58

59. まとめ
2016.4.12 @WP-D Week Day 2 59

60. CSS が生まれて20年ちょっと、テーブルレイアウトからの転換
が起こって10年くらい。まだまだ、これから変わっていくんだ
と思います。
やはり、プログラミングにおける設計のノウハウはかなり入っ
てきているので、勉強してみると、いろいろ役立つ知識・考え
た方が手に入ります。プログラミングが解らなくても使えるこ
とは多いです。
プログラミング原則一覧 - Strategic Choice
オブジェクト指向設計原則 - Strategic Choice
2016.4.12 @WP-D Week Day 2 60

61. ゆるふわ言語な CSS へ怒りや悲しみを覚えることはこれからも
多いと思いますが、WEBデザインへの愛、エンジニアとしての
プライドを持って乗り越えていきましょう。
2016.4.12 @WP-D Week Day 2 61

62. おわり。
Follow Me!
Github: @torounit
Twitter: @Toro_Unit
Facebook: fb.me/torounit
WEB Site: https://torounit.com
2016.4.12 @WP-D Week Day 2 62