読者です 読者をやめる 読者になる 読者になる

まちいろエンジニアブログ

南池袋のWebサービス開発会社、株式会社まちいろのエンジニアブログです。

社内のCSSの管理にルールを持たせよう SMACSS編

CSS

こんにちは、まちいろの門田です。

入社して早一年、主にフロント側で様々なコードを書いてきた次第ですが
最初は個人で書いていた時の癖でひたすらルール無用で好き勝手ガリガリ書いており、なんとも汚いコードが出来上がっておりました。

「まあ、とりあえずデザイン通りの見た目なら・・・」という気持ちが先行してのことなのですが・・・
結果、後々の機能改善や保守の際にどこを直せば、どれを消せばと一つ一つ調べるハメになり
非効率かつ面倒でしかも自分しか理解できなさそうなコード群となっておりました。その上見た目も気持ち悪いですし。

f:id:s_kadota:20160615165219p:plain

ということもありましたし、元々社内で「コレ」といったcssのルールがあったわけでも無いですので
今後のプロジェクトをより効率よく進めていくためにちゃんとしたルールを取り決めようという方針となりました。
チームでプロジェクトを進めていく上でやはりあらかじめルールを決めておくことは、大切です。とても。


まずは主に一般的に普及しているcss設計の手法を、かいつまんでご紹介します。

OOCSS

オブジェクト指向を取り入れた手法。

  • 構造部分と見た目部分を別で作成しそれぞれのクラスなどで呼び出す。
  • 要素ごとを独立して定義する。

など、一度定義したものを他でも使いまわしたりすることを前提にしているものです。
全体の記述量も減りますし、修正時も一括で行えたりと便利です。

SMACSS

サイトを作成するにあたって存在する様々な要素をカテゴリで分けて管理するものです。
基盤となるcssはココ、ページごとのデザインはココ、汎用的なボタンやアイコンはココ・・・など
しっかりとディレクトリ毎に管理し、どこに何が書かれているかをメンバー間で共有できます。
基本的に五つのカテゴリ、

名称 内容
Base サイトの基本スタイル。リセットやフォントサイズ、行間など。
Layout ヘッダーやフッターなどの各所のレイアウトを管理。
Module ボタンやフォームなどサイト内で多数使用されると思われるパーツの管理。
State 要素の状態を管理する。JavaScriotでの切り替えなどに使用する。
Theme サイト全体のテーマの管理。背景色や文字色など。

で分けて考えられますがこれらの分類も社内で独自に定義するのが良いと思います。

BEM

BEMもSMACSS同様カテゴリに分けられます。

名称 内容
Block Webページを構成する大元の要素。ヘッダーやセクションなど。
Element Block内の要素。ヘッダー内のナビゲーションなど。
Modifier Block、Elementの見た目を変える要素。

そしてさらに、厳格な命名規則で管理される手法です。
クラス名を付与する際には「Block__Element--Modifier」など、どこのBlockのどこのElementに対して
使用しているcssなのかがクラス名の時点ではっきりと分かる様に定義するものです。
管理が徹底されていますが、作業スピードが少し他に比べて遅れ気味になるデメリットも含んでおります。

FLOCSS

上記の手法の様々な要素を取り入れた手法です。
レイヤー構成の考え方なども取り入れられておりルールもしっかりと定められ、まとまっております。
ただし元となったOOCSSやSMACSSを知っておくことが望ましいので、css設計に足を踏み入れたばかりの方が
いきなりこの手法を取り入れるのはあまりお勧めしません。
しかし発案者が日本の方ということもあり、ドキュメントなどは日本人向けに揃えられており分かりやすいです。


他にも様々な手法が存在します。興味のある方は是非調べてみてください。

さて、上記の手法の中でもまちいろではどの手法を基に社内CSS設計を組み立てていくか、ですが...
「SMACSS」を参考にしたCSS設計を社内で用いていく方針となっております。

カテゴリに分類し管理していくのはCSSに限らず用いるケースも多いですし、
入り易さもあり、拡張性も大きいとのことで取り入れようと考えました。

SMACSS

それではSMACSSに焦点を当てて基本的にどのような手法が定義されているかを記述していきたいと思います。
カテゴリに分けて管理する...と上ではご説明しましたがそのカテゴリごとの役割や推奨ルールなどをもうすこし
踏み込んでご説明していきます。

Base

Baseカテゴリ、運用する上ではBaseフォルダ等と呼ぶかと思いますがこちらはサイトの基本的な情報をまとめていく場所になります。
例えばまず一番最初にブラウザ間であらかじめ用意されているデフォルトCSSをリセットするreset.cssを適用させるかと思いますが それはこちらの管理下に置くことになります。
プロジェクトのスタート時にまず最初に行うアレコレ、それらがここに置かれるものだと思っていただければ。

他にはサイト全体のフォントや、リンクカラーなどを定義しておくなどでしょうか。

body.css



body{
  font-size:12px;
  font-family:'Meiryo';
  line-height:1.3
  color:#111111;
}

a{
  color:#eeab33;
  text-decoration:none;
}

a:hover{
  opacity:0.5;
  text-decoration:underline;
}

f:id:s_kadota:20160616173456p:plain

Layout

Layoutはその名の通りサイト内の様々なレイアウトを管理する場所です。
ヘッダー、フッター、サイドバー、コンテンツ、ナビゲーション......などなど。
それらをレイアウト別にcssで管理し、どの箇所がどのcssを参照しているかをわかりやすくします。

また、レイアウトに関するクラス名を付与するさには頭に「 l- 」や「 layout- 」などをつけることが推奨されています。
要するにこれはレイアウトのクラスですとすぐに分かるクラス名をつけましょうということですので、ここの名称も
社内で独自に定義して広めていきましょう。

header.css



l-header{
  width:960px;
  height:100px;
  padding:20px 0px;
}

l-header-inner{
  width:100%;
  margin:0 auto;
}
sidebar.css



l-sidebar{
  width:200px;
  float:right;
  padding:10px;
}

f:id:s_kadota:20160616181015p:plain

Module

Moduleはサイト内で使用する様々なパーツ、ボタンや入力フォームなどを管理するカテゴリです。
OOCSSの様に一度作成したものを他所でも使える様にという考え方がこのカテゴリにも表れています。
使いまわせるということは無駄を省き効率が上がるのと同時にサイト内のテイストに統一感を持たせることができます。
都度都度ボタンなどのスタイルを作っていては微妙な差異が生まれてしまうことも少なくありません。
可能な限り、サイト内で多く使用されるものはどこでも使える様に定義いたしましょう。

また、Module内にも構造と見た目を分けた呼び方があり構造側を「Base Module」、
見た目側を「Sub Module」と呼んだりします。

button.css



/*大きいサイズのボタンの構造(base)*/
large-btn{
  width:150px;
  padding:15px 0px;
  text-align:center;
  border:none;
  border-radius:5px;
}

/*小さいサイズのボタンの構造(base)*/
small-btn{
  width:80px;
  padding:10px 0px;
  text-align:center;
  border:none;
  border-radius:3px;
}

/*完了ボタン用の見た目(sub)*/
comp-btn{
  background-color:#333;
  color:#fff;
}

/*キャンセル用の見た目(sub)*/
can-btn{
  background-color:#fff;
  color:#333;
}

大きいサイズのキャンセルボタンを作る場合は、buttonタグのクラスに
「large-btn can-btn」を入れる感じになると思います。

f:id:s_kadota:20160616183128p:plain

State

Stateは状態を管理するカテゴリとなります。displayの表示非表示、成功時の表示、エラー時の表示等など。
何かしらのアクションが行われた際に適用されるケースが多いと思われますので、基本的にはjavaScript
addClassされるものが定義される箇所になるでしょう。 またpositionのfixや、hoverやactive、そしてCSS3ではアニメーションなどcssのみで完結できる状態の管理などもこちらに書かれたりする事もあるでしょう。

さらにこのカテゴリ下のスタイルが呼び出される際、そのスタイルが最優先で適用される事が想定されていますので Stateに関しては他では推奨されていない「!important」を使っても良いとされています。

error.css



errro-text{
  color:#f00;
  font-size:bold;
}

error-box{
  background-color:#ffdc87;
  text-align:center;
}

display.css



disp-hide{
   display:none !important;
}

disp-show{
   display:block !important;
}

f:id:s_kadota:20160616184838p:plain

Theme

Themeはサイト全体の背景色や文字色などをテーマ毎に管理するカテゴリです。
例えば地域毎に同じテイストのサイトを設けた場合、構造は全く同じでも差分化するために
背景色や背景画像、文字色を変えたりする事があると思います。そういった際に読み込むcssの管理場所となります。
また、サイトの訪問者によっては言語を変えたい場合もあるでしょうし、
製作者の遊び心でボタン一つでサイトの雰囲気をガラリと変えたりなどするケースなどもあるのではないでしょうか。

area.css



/*東京用サイトはモノクロをベースにする*/
theme-tokyo{
  background-color:#aaa;
  color:#333;
}


/*神奈川用サイトは青をベースにする*/
theme-kanagawa{
  background-color:#3377EE;
  color:#fff;
}

f:id:s_kadota:20160616185813p:plain

社内独自の設計

上記で述べた事以外でもSMACSSのより細かなルールや設計について詳細に記されたサイトがいくつも出てくるかと思います。
しかし完全にSMACSSを模倣するのではなく、カテゴライズするという考え方や命名規則などを参考に
チームメンバーで最も共有しやすい形を探し社内独自の設計をするのが最も効率的な形になると思います。

プロジェクトの規模によってはカテゴリの数は4つ、あるいは3つにしても良いでしょうし、
各カテゴリ名もより馴染みのある単語に置き換え何が属するかるなど決めていきましょう。

私自身もまだ社内のCSS設計を確立していないため日々勉強しより良いものに形作ることを心がける毎日です。


さて、カテゴリや用途ごとにCSSのファイルを分類して作成してきましたが
これらを単純にhtmlに読み込む場合head内に膨大な量の記述が必要になってしまいます。

<head>
    <link rel="stylesheet" href="css/base/reset.css">
    <link rel="stylesheet" href="css/base/body.css">
    <link rel="stylesheet" href="css/layout/header.css">
    <link rel="stylesheet" href="css/layout/footer.css">
    <link rel="stylesheet" href="css/layout/sidebar.css">
    <link rel="stylesheet" href="css/layout/contents.css">
    ・
    ・
    ・
    ・
    ・
    <link rel="stylesheet" href="css/theme/area.css">
</head>

見栄えも悪い上に管理しづらいですし、CSSが増えるごとに都度都度で追記が必要に......となってしまいます。
単純にCSSのみを使って行う場合はこれも仕方のないことですが、CSSメタ言語の一つである「SASS」を活用すれば
管理もコードの記述もグッと速く、楽になります。

次回のCSS設計の続きは、SASSに関して触れてみようかと思います。