リファクタリングHTML/CSS ～レガシー世界を超えて～ #scripty03

リファクタリング 
HTML/CSS
ヤフー株式会社 
マーケティングソリューションカンパニー 
開発本部エクスペリエンスデザイン部 
テクニカルデザイン 
 
ヒラヤナオコ
∼レガシー世界を超えて∼

Copyright (C) 2015 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
ふんわり自己紹介
美術史出身のエクストリーム文系
アプリデザインや大規模サイト運用を経て
ペライチとか作る係

広告管理ツール

掘れば何か出てくる 
超巨大遺跡(現役)
もともと大規模なシステム
度重なる仕様・機能追加
設計担当者も実装担当者も変わる

掘れば何か出てくる 
超巨大遺跡(現役)
もともと大規模なシステム
度重なる仕様・機能追加
設計担当者も実装担当者も変わる
カオス!!

見た目は 
同じはず?
ひとつのスタイルを当てるのに、
機能をクラス名にしてしまうと
こうなる。
.myModule .orenoBtn,
.myModule .omaenoBtn,
.myModule .oreToOmaenoBtn,
.myModule .kiminoBtn,
.myModule .anatanoBtn,
.myModule .kimitachinoBtn,
.myModule .oregaOmaedeOmaegaOredeBtn,
.myModule .oregaOretachigaBtn,
.myModule .darekanoBtn,
.myModule .karenoBtn,
.myModule .kanojonoBtn,
.myModule .anoBtn,
.myModule .konoBtn,
.myModule .sonoBtn,
.myModule .donoBtn,
.myModule .yabaiBtn,
.myModule .sugoiBtn,
.myModule .choberibaBtn,
.myModule .mk5Btn,
.myModule .kaeruBtn {
display:inline-block;
width:15px;
height:15px;
background:no-repeat url(icon.gif) 0 4px;
text-decoration:none;
overflow:hidden;
margin:0 0.2em 0 0;
cursor:pointer;
}

その親要素、
要るの?
親要素が違う場合はどうなるん
だろうと不安になるセレクタ群。
 
yellowIconという同名で異なる
画像を使用するパターンがある
のだろうか……。
.myModule .yellowIcon,
span .yellowIcon,
p .yellowIcon { 
display:inline-block; 
width: 15px; 
height: 15px;
background:no-repeat url(icon.gif) 0 4px;
}

遺跡の修繕、 
リファクタしよう
の、HTML/CSS編

迷路状態
ドキュメント：なし
構造、記法のルール：なし
パーツごとの標準的な仕様：なし
作ろう
決めよう
見直そう

ドキュメント

スタイルガイド(KSS)
KSS
様々な言語でジェネレータがある
導入コストは高いが柔軟で、 
比較的記述しやすい
無駄なCSSの増殖を抑制…できるといいな

その他スタイルガイド
StyleDocco
導入は簡単（gulp,grunt,etc）
Modiﬁerまでマークアップするのが面倒
DSS
Javadoc風の記法
多くのプリプロセッサに対応
コメント補助Sublimeプラグインがある
node,grunt環境ならオススメ

その他ドキュメント
構造やルールの説明
GithubのWikiに記載
mixinやfunctionの説明
必要に応じてSassDocを利用予定
mixinに頼る設計ではないため現状ナシ

構造、記法

BEM
コンポーネントの使い回しが多い
複雑化しても詳細度が上がらない 
※改造してModiﬁerは詳細度上がる

.Block__element
.m-odifier

.Block 
__element
.m-odifier
modiﬁerだけ別クラス化。 
ただしmodiﬁer単体のルール
セットは存在しない。

粒度をそろえる
基本的な考え方はBEM
Block, element, modiﬁer
でもコンポーネントの粒度は捉え方次第
粒度の考え方をルール化してしまう

粒度のルール(の一例)
elementは1階層まででネストはしない 
1つのBlockが持つことができるelementは 
基本4種類＋リンク
機能や見た目ではなく、 
このルールが適用できる粒度に分解する
.Block__element__elementino

基本4種類 
+リンク
head
body
item
foot
link
body
item
item
item
head
foot
link
Block

例

例
Block

例
Block
head
body
foot

例
head
body
foot
?
?
Block

例
Block
head
item
item
item
foot
item.m-thumb
item

例
TopixList
TopixBox

例.css
こんな感じに。
/* ボックス全体 */
.TopixBox { 
width: 300px; 
border: 1px solid #9eb4db;
}
.TopixBox__head { 
padding: 0; 
} 
.TopixBox__body { 
padding: 3px 7px;
}
.TopixBox__foot { 
padding: 10px 5px;
}
!
 
/* タイトルの一覧 */
.TopixList {
width: 100%;
}
.TopixList__head { 
font-size: 11px; 
padding-bottom: 5px;
}
.TopixList__item {
padding: 3px 0;
}
.TopixList__item.m-thumb {
position: absolute;
}

例2

例2.scss
Sass3.4なら記述もスッキリ。 
head, body, footはそれぞれ、
hd, bd, ftと省略。
.PageInfo {
padding-top: 10px;
padding-bottom: 20px;
!
&__hd {
font-weight: bold;
}
&__bd {
color: #777;
}
}
 
.RegisterGroup {
padding-left: 1.5em;
!
&__hd {
border-bottom: 1px solid #E8E8E8;
}
&__bd {
padding-bottom: 1.5em;
}
&__item {
padding: 0.8em 0;
}
}
 
.RegisterUnit {
@include clearfix;
!
&__hd {
float: left;
width: 13em;
text-align: right;
}
&__bd {
padding-left: 13.5em;
}
}

でも柔軟に
名前は一例
もちろん例外もある
__inputとか、__btnとか
1つのBlockが抱えられる 
elementの種類の上限を定めると良さそう

ルールの分けかた
.A…エラー表示用、別パターンなし
.B…お知らせ用、色・アイコンパターンあり

やり方色々
.iconLabel
共通のスタイルにはO.O的な細かい汎用クラスを作成。
.panel.m-typeDenger
.closeButton

やり方色々
Block, elementごとに記述
.ErrorPanel { 赤枠、赤背景、アイコン付き太赤字 }
.NotePanel { 赤枠、赤背景 }
.NotePanel__hd { アイコン付き赤太字、下点線 }
.NotePanel__ft { 閉じるボタン }

ルールを明確に

BEMコンポーネント 
＋ 
汎用パーツ

構成
base/
elements/
modules/
pages/
stickers/
style.scss
.
├── base
│   ├── _layouts.scss
│   ├── _reset.scss
│   ├── _variables.scss
│   └── mixins
├── elements
│   ├── _buttons.scss
│   └── _labels.scss
├── modules
│   ├── _noticePanel.scss
│   ├── _searchBox.scss
│   └── common
│   └── _header.scss
├── pages
│   ├── _confirm.scss
│   └── _create.scss
├── stickers
│   └── _spacers.scss
└── style.scss

base
ノーマライズやリセット、レイアウト
変数、関数、mixin
基本的にプロジェクト開始時に整備し、 
あとはあまり弄らない

elements
MCSSでいうベースレイヤー
ボタン、ラベルなどの汎用パーツ
階層構造を持たず、それ自体で完結
.lowerCamel(.button, .iconLabel, …)
外部に影響するレイアウト情報は 
持たない(margin, ﬂoatなど)

modules
MCSSでいうプロジェクトレイヤー
複数要素からなるBEMコンポーネント群
.UpperCamel (.NotePanel, .SearchBox)
内側に対してのみレイアウトを変更できる
（paddingを持ってよい、elementはmarginも持ってよい）

pages
ページ固有のスタイルを記述
上書き用ではない
ページ名に関連付いた接頭辞などで 
名前をユニークに

stickers
一時的なレイアウト変更など
シングルルールのクラス
.s-sticker
ここでのみ!importを利用する

style.scss
全てのパーシャルを読み込む
ディレクトリはアルファベット順なので 
そのままの順番でOK
pagesレイヤーが重くなってきたら、 
pagesだけ別に出力してもOK

UI仕様

UI仕様もソースから
同機能でもUI仕様がブレブレ 
配置、サイズ、色……
似た名前やモディファイアが大量発生
ソースの肥大化・複雑化を招く

例
.VerticalList__link

UI仕様もソースから
ソースを読めばルールがわかる
新規モジュールを作るときは 
スタイルガイド＋該当ルールセットを参照
ソースの肥大化・複雑化を抑止!!したい!!

まとめ
まずはドキュメント環境をつくる
リファクタしながらルールを作る
仕様のブレはソースから直す

ご静聴ありがとう
ございました。

リファクタリングHTML/CSS ～レガシー世界を超えて～ #scripty03

Recommended

More Related Content

What's hot (20)

Similar to リファクタリングHTML/CSS ～レガシー世界を超えて～ #scripty03 (20)

More from Yahoo!デベロッパーネットワーク (20)

リファクタリングHTML/CSS ～レガシー世界を超えて～ #scripty03