運営者情報

運営してるひと: @sters9

       

妻と猫と横浜あたりに住んでいる。最近は Go や Kubernetes や GCP をしています。 PHP や JavaScript もすこし。

プライバシーポリシー

tools.gomiba.co

アーカイブ

2021/02 (12) 2021/01 (8)

2020/05 (2) 2020/04 (2) 2020/02 (2) 2020/01 (1)

2019/12 (3) 2019/11 (2) 2019/10 (5) 2019/09 (3) 2019/07 (6) 2019/06 (4) 2019/04 (3) 2019/01 (2)

2018/12 (6) 2018/10 (4) 2018/09 (6) 2018/08 (7) 2018/07 (16) 2018/06 (7) 2018/05 (7) 2018/04 (5) 2018/03 (3) 2018/02 (10) 2018/01 (6)

2017/12 (8) 2017/11 (6) 2017/10 (10) 2017/09 (12) 2017/08 (12) 2017/07 (3) 2017/06 (1) 2017/01 (4)

2016/12 (5) 2016/10 (3) 2016/09 (1) 2016/07 (2) 2016/06 (1) 2016/04 (1) 2016/02 (1) 2016/01 (2)

2015/12 (1) 2015/10 (1) 2015/09 (3) 2015/06 (1) 2015/01 (1)

2014/08 (2) 2014/07 (3) 2014/05 (1) 2014/01 (7)

2013/12 (2) 2013/11 (4) 2013/10 (1) 2013/09 (1) 2013/08 (3) 2013/07 (4) 2013/06 (5) 2013/05 (2) 2013/04 (7) 2013/03 (1)

CSS設計の教科書を読んだ@途中まで

この記事は公開されてから1年以上経過しており、情報が古くなっている可能性があります。

こんにちは、ごみばこです。

最近になってようやく、ちゃんとしっかり CSS の教科書を読みました(設計の大事さと紹介まで)。そのメモというか、まとめです。CSS 設計マジ大事やなー。

Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法 | 谷 拓樹 |本 | 通販 | Amazon

余談ですけど、ここのところブログをちょこちょこ書いているのですが、トップページが遊び要素メインで中身が無いと見なされてか Adwords も Amazon アソシエイトも審査落ちしたので、ごみばこいんからのリンクはノーアフィリエイトです。かなしみ、ビールの一杯くらい稼いだっていいじゃない

CSS設計がなぜ重要か

フロントエンドも作って終わりではない。 web サイトのコンテンツが増えたり、キャンペーンをしたりなど、 web サイトの内容が変わっていくので、それに合わせて各コードのメンテナンスをしていかないといけない。それはもしかしたら誰かに引き継ぐかもしれないし、自分でやるかもしれない。リッチな表現が求められる今の web サイトでは HTML も Javascript も CSS も複雑なものになっていく。

中でも CSS はシンプルに書ける一方でたくさんの記述が必要がゆえ、複雑なことをしようとすると、スパゲッティコードになりやすい。だから設計というルールを設けていく。 プログラミングと同様に CSS も設計をすることで、予測しやすい、再利用しやすい、保守しやすい、拡張しやすい、ものを記述できるようになる。

設計をどうやっていくか

見た目の変更や入れ替えがあるなかで、使いまわすようなものも多くある。その使いまわしのために、要素を部品=モジュール、コンポーネントと考えていく設計が有効になる。 そのコンポーネントとして考えるために、いくつかの実際に活用されている設計方針を紹介していく。

OOCSS

Object-oriented CSS

構造と見た目の分離、コンテナとコンテンツの分離を挙げている。 コンポーネントとしての構造、ブラウザ上での見た目を分離して考えること。ある要素がどこにいるかのコンテナ、ある要素のコンテンツを分離して考えること。

後者は難しいが「場所に依存しないセレクタを書くこと。どこそこの中にある○○、とし定義されるようなものを避けること」と考えるとわかりやすい。

SMACSS

Home - Scalable and Modular Architecture for CSS

OOCSS で言われている分離を実践するためのカテゴリが決められている。

Base :見た目のリセット、標準化 Layout:全体的なレイアウト設定(2カラムなの、3カラムなの、ヘッダー?) Module:コンポーネント自体 State :コンポーネントの状態 Theme :コンポーネントの見た目違い

もう一つのSMACSSのポイントとして「HTMLとCSSの分離」が挙げられている。

要するに。 SMACSS = OOCSS + OOCSSを使うためのカテゴリ + HTMLとCSSの分離

BEM

BEM — Block Element Modifier

CSSにおける命名規則の提案。OOCSS、SMACSSを考えてのコンポーネントを記述できるよう規則が決められている。

Block Elementの集合体、ひとつのコンポーネント 命名は自由

Element コンポーネントに含まれる要素の1つ1つ 命名は Block_Element という形式

Modifier BlockとElementについて、場合分けが起こるときに使う 命名は Block__Modifier または Block_Element__Modifier という形式

たしかにBEMでは、アンダースコアを付けるように、と言っているがそれはさほど重要ではない。キャメルでもハイフンでもいい。コンポーネントの体に合わせた命名規則を設けることで、シンプルにたくさん書けるCSSへ規律をもたらし、事故を未然に防いだり可読性を上げることが大事。

MCSS

MCSS

SMACSS にレイヤーというルールを足すようなもの。複数のレイヤーを構成することによってCSSを設計する。レイヤーとして縛りを設けることで、CSSプロパティの汚染を防いでいく。

Foundation プロジェクトの土台、resetcssやnormalize.cssがそれ 最初に読み込まれる

Base コンポーネント定義 他のレイヤーから拡張変更ができる必要がある Baseレイヤーコンポーネントは上書きできる

Project 具体的なページを構成する要素、Baseレイヤーコンポーネントの集まり。現実的にはこのレイヤーが厚くなりがちだけど、上書きによって階層が深くならないようにする Baseレイヤーコンポーネント、Projectレイヤーコンポーネントを上書きできる

Cosmetic 下層レイヤーコンポーネントに含まれないちょっとしたスタイル。ヘルパー、ユーティリティのようなもの、グローバルなModifierなど。 基本的に上書きは出来ない

Context 例外的なレイヤー。すべてを上書きできる。 特定のブラウザ、デバイス、状況によって切り替えるようなもの。PC / スマホ、ログインしてる / してない。 セクションを持たず、各コンポーネントについて書かれるセクションの中で記述される。

レイヤーの分け方に合わせて、CSSを記述するときの基本原則がいくつかある。

  • コンポーネントを1つのセクションにまとめる
  • Modifierを個別クラスにし、単体で利用しない
  • コンポーネントのカスケーディング(上書き)が出来る
  • あるコンポーネントに含まれる別のコンポーネントに適用するスタイル。ただし上層のコンポーネントを上書きしてはいけない。同じ層か、下層のみ上書き可能
  • クラス名を略語にする

FLOCSS

この本の筆者が考えている、全部まぜのいいとこ取り。

ソースファイルのセクションわけ、レイヤー制約、命名制約が盛り込まれている。詳細は Github で! hiloki/flocss: CSS organization methodology.

ルールこそ多いように見えるが、ルールに乗れると非常に楽(体験談)

ここまで読んで

個人的なちょっとしたやつで Bootstrap を入れた上で、新たに書き足す部分を FLOCSS を意識して作ったところ、非常にわかりやすく、事故もなく、安心安全にできてちょっと感動してました。 …、とはいえ FLOCSS でみんなやろうぜ!というわけではなく。本にも書かれているのですが、色々な考え方があるけど俺達はどうやってやるよ、というのを改めてちゃんと考えないとね、って思いましたとさ。

いじょ。