リファクタリング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） Modifierまでマークアップするのが面倒

DSS Javadoc風の記法多くのプリプロセッサに対応コメント補助Sublimeプラグインがある

node,grunt環境ならオススメ


その他ドキュメント

構造やルールの説明 GithubのWikiに記載

mixinやfunctionの説明必要に応じてSassDocを利用予定 mixinに頼る設計ではないため現状ナシ


構造、記法


BEM

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


.Block__element

.m-odifier


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


粒度をそろえる

基本的な考え方はBEM Block, element, modifier

でもコンポーネントの粒度は捉え方次第

粒度の考え方をルール化してしまう


粒度のルール(の一例)

elementは1階層まででネストはしない

1つのBlockが持つことができるelementは基本4種類＋リンク

機能や見た目ではなく、このルールが適用できる粒度に分解する

.Block__element__elementino


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

body

item

item

item

head

foot

link

Block


例


例Block


例Blockhead

body

foot


例

head

body

foot

??

Block


例

Block


例

Block headitemitemitem

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, floatなど)


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仕様もソースから

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


まとめ

まずはドキュメント環境をつくる

リファクタしながらルールを作る

仕様のブレはソースから直す


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

Technology

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