enduring css

71

Upload: takazudo

Post on 22-Mar-2017

673 views

Category:

Engineering


4 download

TRANSCRIPT

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 button_play">...</button>

BEM

block__element--modifier

Block .tabElement .tab__itemModifier .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 */ .pd-ItemDescription { ... } .pd-ItemMainPhoto { ... } .pd-Carousel { ... }

/* ��������� shoppingCart modules */ .sc-ItemList { ... } .sc-UserInfo { ... }

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 └── topPage ├── topPage.css └── topPage.js

.namespaces ├── common │ ├── common.css │ └── common.js ├── productDetail │ ├── productDetail.css │ └── productDetail.js └── topPage2 ├── topPage2.css └── topPage2.js

分離しなかったら?旧topPageリソース消せないですよね?

このCSS消していいんだろうか…

この画像どこに置けばいいんだろう…

このモジュール変更するのが怖い

いや、そもそも変更出来ないし消せない

4.クラス名の命名規則BEM的命名規則に名前空間の考えを足したもの

BEMでは……Block .tabElement .tab__itemModifier .tab__item--active

<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>

ECSSでは…….ns-Module_ChildNode-variant

Module .tp-TabChild node .tp-Tab_ItemVariant [aria-current="true"]

variantにはwai‒ariaとかも使うと良いぞと

<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>

モジュールの 汎用性について

汎用的にしたら複雑になる

一度作ったモジュールは二度と消せない

無限に増えるモディファイア

運用の負荷も上がる

最初の想定が貫き通せるとは限らない

汎用的にしても管理しきれないのでは?

汎用的なものをつくってもいい しかしそれは消せなくなる

モジュールの名前についてこれも汎用さを考えるからややこしくなる

そのモジュールのになう機能名称をつければいい

名前空間で重複は避けられる

本当に完全に分けるのか?必ずしもそう強制するわけではない

汎用的に使える名前空間 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