Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Enduring CSS
高津戸壮 @Takazudo
自己紹介
高津戸壮 (たかつど たけし)
フロントエンドエンジニア
株式会社ピクセルグリッド
@Takazudo
Enduring CSSって何?略してECSS
CSS設計思想の一つ
を著した本
Ben Frain著
サイトで全部読める 
そんなに有名でもない
ecss.io
ECSSの特徴Enduring: 長続きする、永続的な、 
不朽の、我慢強い、辛抱強い
デカくてスケールするサイト向け
色々試したけど違うなーって思って考えたらしい
設計ルール + ヒント集
ECSSを紹介したいワケ私とCSS
いかにCSSを設計するか 
エンドレスな悩み
自分的にそのブレイクスルーだった
ECSSの考えはCSS設計における 
ベースの考え方となりうるなぁと
その前に… 
著名なCSS設計思想
ざっくり紹介
OOCSS
BEM
SMACSS
OOCSS
<button class="button button_caution">...</button>
<button class="button button_pdf">...</button>
<button class="button bu...
BEM
block__element--modifier
Block .tab
Element .tab__item
Modifier .tab__item--active
SMACSSBase ‒ ベースルール
Layout ‒ レイアウトルール
Module ‒ モジュールルール
State ‒ 状態(ステート)ルール
Theme ‒ テーマ
だいたいこんな感じモジュール化して考えよう
クラス名の命名規則で衝突を防ごう
CSSルールを分類して管理しよう
解決できない悩み
モジュールの汎用性
モジュールの粒度
モジュールの名前
どう考えれば?
 
抽象化による解決
 
分離による解決
Atomic Design
Enduring CSS
Enduring CSSの考え基本はモジュール化
ただし、抽象化しない
その先には複雑化が待っている
結果としてメンテナンスのコストが増えすぎる
分離することによって解決する
時間とともに変化する状況で 
完全な抽象化など不可能である
1. モジュール化
2. 名前空間
3. アセットの分離
4. クラス名の命名規則
1.モジュール化そんな細かくはしない
ネストしたりもなるべくしない
共通の細かいUIを抜き出してモジュールにしない
モジュールは機能のまとまり単位で考える
モジュールには名前をつける
ecss.io
 
同じようなものも別物 
なぜか?そっちのほうが分かりやすいから
複雑化を防ぐことができるから
同じようなCSSを何度も 
書かないといけないのでは?
それでもいい。gzipとかすればいい
モジュールの粒度たくさんのモジュールを集めて 
ひとかたまりのUIを作ってもよいよ?
ECSSでは分離できることを重要と考える
ECSSにおけるモジュールの定義 
「視覚的に認識できる 
個別の機能領域のもっとも大きな区分」
2.名前空間モジュールを名前空間でグルーピングする
TopPage, ProductDetail, ShoppingCart
/* topPage modules */
.tp-MainVisual { ... }
.tp-Carousel { ... }
.tp-NewsList { ... }
/* 商品詳細 productDetail modules */
.p...
common
/* 共通 common modules */
.cmn-Header { ... }
.cmn-Footer { ... }
.cmn-SideAd { ... }
名前空間の分け方例これまあくまで例
CMSで出しているテンプレートが違う
ここだけWordPressで出している
サイト全体で共通
管理する部署が違う
大きくても小さくてもご自由にどうぞ
3.アセットの分離名前空間ごとに読み込むCSS、JS、画像類を完全に分離
例えばこう
.namespaces
├── common
│ ├── common.css
│ └── common.js
├── productDetail
│ ├── productDetail.css
│ └── productDetail.js
└...
.namespaces
├── common
│ ├── common.css
│ └── common.js
├── productDetail
│ ├── productDetail.css
│ └── productDetail.js
└...
分離しなかったら?旧topPageリソース消せないですよね?
このCSS消していいんだろうか…
この画像どこに置けばいいんだろう…
このモジュール変更するのが怖い
いや、そもそも変更出来ないし消せない
4.クラス名の命名規則BEM的命名規則に名前空間の考えを足したもの
BEMでは……
Block .tab
Element .tab__item
Modifier .tab__item--active
<div class="tab">
<button class="tab__item">One</button>
<button class="tab__item tab__item--active">Two</button>
<button ...
ECSSでは……
.ns-Module_ChildNode-variant
Module .tp-Tab
Child node .tp-Tab_Item
Variant [aria-current="true"]
variantにはwai‒ar...
<div class="tp-Tab">
<button class="tp-Tab_Item">One</button>
<button class="tp-Tab_Item" aria-current="true">Two</button>...
モジュールの 
汎用性について汎用的にしたら複雑になる
一度作ったモジュールは二度と消せない
無限に増えるモディファイア
運用の負荷も上がる
最初の想定が貫き通せるとは限らない
汎用的にしても管理しきれないのでは?
汎用的なものをつくってもいい...
モジュールの名前についてこれも汎用さを考えるからややこしくなる
そのモジュールのになう機能名称をつければいい
名前空間で重複は避けられる
本当に完全に分けるのか?必ずしもそう強制するわけではない
汎用的に使える名前空間 sw(SiteWide)の例
PostCSSやSassの変数の利用は推奨 
(色、マジックナンバー、z‒index)
mixinの使用も許可。ただし最小限 
そこ...
ECSS以前のワタシ抽象化による整理
それこそがクールなCSS設計
CSSが複雑?まぁ仕方ない
デザインも統一、整理してこそ良い設計
変更されるデザイン
増え続けるモジュール
なかなかうまくいかないナァ
ECSS以後のワタシすべてを一緒にして考える 
そのスタートラインが間違ってた
まずは分けて考える
その上で共通化できるところを考える
CSS設計のミニマルさだけが美しさではない
あとで編集することを考えたらどう設計すべきか
デザインが統一され...
ECSSに習うべきか?ガチガチにECSSに従う必要は別にない
分けて管理したらどうか?という視点
Webアプリケーション向けと著にはある
汎用コンポーネントを組み合わせて 
デザインしたい場合にはそこまで向かなそう
部分的に考えを採用しても意味...
汎用モジュールで貫くかスタイルガイドや運用体制を確立できる環境か?
設計~運用までタッチできるか?
Atomic Designを参照
どうECSSの考えを 
適用するか
汎用的なモジュールで構成する場合
基本は汎用的な名前空間に属させる
キャンペーンやランディングページだけ分ける
デザインが似ているが別管理の場合
例えばコーポレートサイト&ECサイト
デザインのトーン同一、別部署や会社が管理とか
一緒にして運用することが難しそうなら分けても
テンプレートが断片化する場合
そういう状況でさらに細かいモジュールが 
組み合わさっているとだいぶツライ
このviewのコードは全部ここにあるよ 
そういう状態のほうが楽かもしれない
Enduring CSSまとめ管理できることが大事
スケールできることが大事
そのために抽象化を諦める
ミニマムなCSSを目指すものではない
最高のパフォーマンスは求めていない
運用や設計指針に応じて採用してみてはいかが?
ありがとう 
ございました
Enduring CSS
CodeGrid ‒ Enduring CSSの設計思想
CodeGrid ‒ 知っておきたいHTMLテンプレート設計法
HTML5 Experts.jp ‒ Enduring CSS
Enduring CSS
Enduring CSS
Enduring CSS
Enduring CSS
Enduring CSS
Enduring CSS
Enduring CSS
Enduring CSS
Enduring CSS
Enduring CSS
Enduring CSS
Enduring CSS
Enduring CSS
Enduring CSS
Enduring CSS
Enduring CSS
Enduring CSS
Enduring CSS
Enduring CSS
Upcoming SlideShare
Loading in …5
×

Enduring CSS

2,715 views

Published on

Frontend Conference 2017@大阪 新梅田研修センターにて。

Published in: Engineering
  • Be the first to comment

Enduring CSS

  1. 1. Enduring CSS 高津戸壮 @Takazudo
  2. 2. 自己紹介 高津戸壮 (たかつど たけし) フロントエンドエンジニア 株式会社ピクセルグリッド @Takazudo
  3. 3. Enduring CSSって何?略してECSS CSS設計思想の一つ を著した本 Ben Frain著 サイトで全部読める  そんなに有名でもない ecss.io
  4. 4. ECSSの特徴Enduring: 長続きする、永続的な、  不朽の、我慢強い、辛抱強い デカくてスケールするサイト向け 色々試したけど違うなーって思って考えたらしい 設計ルール + ヒント集
  5. 5. ECSSを紹介したいワケ私とCSS いかにCSSを設計するか  エンドレスな悩み 自分的にそのブレイクスルーだった ECSSの考えはCSS設計における  ベースの考え方となりうるなぁと
  6. 6. その前に…  著名なCSS設計思想 ざっくり紹介
  7. 7. OOCSS BEM SMACSS
  8. 8. OOCSS
  9. 9. <button class="button button_caution">...</button> <button class="button button_pdf">...</button> <button class="button button_play">...</button>
  10. 10. BEM
  11. 11. block__element--modifier Block .tab Element .tab__item Modifier .tab__item--active
  12. 12. SMACSSBase ‒ ベースルール Layout ‒ レイアウトルール Module ‒ モジュールルール State ‒ 状態(ステート)ルール Theme ‒ テーマ
  13. 13. だいたいこんな感じモジュール化して考えよう クラス名の命名規則で衝突を防ごう CSSルールを分類して管理しよう
  14. 14. 解決できない悩み モジュールの汎用性 モジュールの粒度 モジュールの名前 どう考えれば?
  15. 15.   抽象化による解決   分離による解決 Atomic Design Enduring CSS
  16. 16. Enduring CSSの考え基本はモジュール化 ただし、抽象化しない その先には複雑化が待っている 結果としてメンテナンスのコストが増えすぎる 分離することによって解決する 時間とともに変化する状況で  完全な抽象化など不可能である
  17. 17. 1. モジュール化 2. 名前空間 3. アセットの分離 4. クラス名の命名規則
  18. 18. 1.モジュール化そんな細かくはしない ネストしたりもなるべくしない 共通の細かいUIを抜き出してモジュールにしない モジュールは機能のまとまり単位で考える モジュールには名前をつける
  19. 19. ecss.io
  20. 20.  
  21. 21. 同じようなものも別物  なぜか?そっちのほうが分かりやすいから 複雑化を防ぐことができるから 同じようなCSSを何度も  書かないといけないのでは? それでもいい。gzipとかすればいい
  22. 22. モジュールの粒度たくさんのモジュールを集めて  ひとかたまりのUIを作ってもよいよ? ECSSでは分離できることを重要と考える ECSSにおけるモジュールの定義  「視覚的に認識できる  個別の機能領域のもっとも大きな区分」
  23. 23. 2.名前空間モジュールを名前空間でグルーピングする
  24. 24. TopPage, ProductDetail, ShoppingCart
  25. 25. /* topPage modules */ .tp-MainVisual { ... } .tp-Carousel { ... } .tp-NewsList { ... } /* 商品詳細 productDetail modules */ .pd-ItemDescription { ... } .pd-ItemMainPhoto { ... } .pd-Carousel { ... } /* shoppingCart modules */ .sc-ItemList { ... } .sc-UserInfo { ... }
  26. 26. common
  27. 27. /* 共通 common modules */ .cmn-Header { ... } .cmn-Footer { ... } .cmn-SideAd { ... }
  28. 28. 名前空間の分け方例これまあくまで例 CMSで出しているテンプレートが違う ここだけWordPressで出している サイト全体で共通 管理する部署が違う 大きくても小さくてもご自由にどうぞ
  29. 29. 3.アセットの分離名前空間ごとに読み込むCSS、JS、画像類を完全に分離
  30. 30. 例えばこう
  31. 31. .namespaces ├── common │ ├── common.css │ └── common.js ├── productDetail │ ├── productDetail.css │ └── productDetail.js └── topPage ├── topPage.css └── topPage.js
  32. 32. .namespaces ├── common │ ├── common.css │ └── common.js ├── productDetail │ ├── productDetail.css │ └── productDetail.js └── topPage2 ├── topPage2.css └── topPage2.js
  33. 33. 分離しなかったら?旧topPageリソース消せないですよね? このCSS消していいんだろうか… この画像どこに置けばいいんだろう… このモジュール変更するのが怖い いや、そもそも変更出来ないし消せない
  34. 34. 4.クラス名の命名規則BEM的命名規則に名前空間の考えを足したもの
  35. 35. BEMでは…… Block .tab Element .tab__item Modifier .tab__item--active
  36. 36. <div class="tab"> <button class="tab__item">One</button> <button class="tab__item tab__item--active">Two</button> <button class="tab__item">Three</button> <button class="tab__item">Four</button> </div>
  37. 37. ECSSでは…… .ns-Module_ChildNode-variant Module .tp-Tab Child node .tp-Tab_Item Variant [aria-current="true"] variantにはwai‒ariaとかも使うと良いぞと
  38. 38. <div class="tp-Tab"> <button class="tp-Tab_Item">One</button> <button class="tp-Tab_Item" aria-current="true">Two</button> <button class="tp-Tab_Item">Three</button> <button class="tp-Tab_Item">Four</button> </div>
  39. 39. モジュールの  汎用性について汎用的にしたら複雑になる 一度作ったモジュールは二度と消せない 無限に増えるモディファイア 運用の負荷も上がる 最初の想定が貫き通せるとは限らない 汎用的にしても管理しきれないのでは? 汎用的なものをつくってもいい  しかしそれは消せなくなる
  40. 40. モジュールの名前についてこれも汎用さを考えるからややこしくなる そのモジュールのになう機能名称をつければいい 名前空間で重複は避けられる
  41. 41. 本当に完全に分けるのか?必ずしもそう強制するわけではない 汎用的に使える名前空間 sw(SiteWide)の例 PostCSSやSassの変数の利用は推奨  (色、マジックナンバー、z‒index) mixinの使用も許可。ただし最小限  そこで抽象化はしない 基盤となるレイヤーは極力薄く
  42. 42. ECSS以前のワタシ抽象化による整理 それこそがクールなCSS設計 CSSが複雑?まぁ仕方ない デザインも統一、整理してこそ良い設計 変更されるデザイン 増え続けるモジュール なかなかうまくいかないナァ
  43. 43. ECSS以後のワタシすべてを一緒にして考える  そのスタートラインが間違ってた まずは分けて考える その上で共通化できるところを考える CSS設計のミニマルさだけが美しさではない あとで編集することを考えたらどう設計すべきか デザインが統一されていること  コードとして同一であること  常に一緒ではないかも
  44. 44. ECSSに習うべきか?ガチガチにECSSに従う必要は別にない 分けて管理したらどうか?という視点 Webアプリケーション向けと著にはある 汎用コンポーネントを組み合わせて  デザインしたい場合にはそこまで向かなそう 部分的に考えを採用しても意味があるかも
  45. 45. 汎用モジュールで貫くかスタイルガイドや運用体制を確立できる環境か? 設計~運用までタッチできるか? Atomic Designを参照
  46. 46. どうECSSの考えを  適用するか
  47. 47. 汎用的なモジュールで構成する場合 基本は汎用的な名前空間に属させる キャンペーンやランディングページだけ分ける
  48. 48. デザインが似ているが別管理の場合 例えばコーポレートサイト&ECサイト デザインのトーン同一、別部署や会社が管理とか 一緒にして運用することが難しそうなら分けても
  49. 49. テンプレートが断片化する場合 そういう状況でさらに細かいモジュールが  組み合わさっているとだいぶツライ このviewのコードは全部ここにあるよ  そういう状態のほうが楽かもしれない
  50. 50. Enduring CSSまとめ管理できることが大事 スケールできることが大事 そのために抽象化を諦める ミニマムなCSSを目指すものではない 最高のパフォーマンスは求めていない 運用や設計指針に応じて採用してみてはいかが?
  51. 51. ありがとう  ございました
  52. 52. Enduring CSS CodeGrid ‒ Enduring CSSの設計思想 CodeGrid ‒ 知っておきたいHTMLテンプレート設計法 HTML5 Experts.jp ‒ Enduring CSS

×