CSSをはじめたばかりの人がSCSSを導入すべき3つの理由+α

ちょっと釣り的なタイトルで、色々議論の余地もあると思うのですが・・・
自分を納得させるために少し考えてみました。

SCSSなどのCSSメタ言語は、業務としてCSSを書いているコーダさんにとっては、すごく協力なツールになっていると思います。僕自身、あまり難しいことはしていませんが、もはやコーディングをする際にはなくてはならないものになっています。
では、CSSを勉強しはじめた人にとってはどうなのかな?という所ですが・・・
僕個人としては、積極的に使っていった方がいいのではないかと思っています。

理由1 CSSの構文が間違っていたらエラーを吐いてくれるから

CSS自体は、それほど難しい構文を書く訳ではないのですが、慣れていないと凡ミスをすることがよくあります。(よくありました。)
そういった場合、通常のエディタですと、なかなか構文チェックまでしてくれないのですが、SCSSを使って書くと、CSSの構文が間違っている場合、エラーを出してくれるので、ミスに気付きやすくなります。(Preprosでコンパイルすると)
間違いに気付かせてくれるというのは、大きな勉強になると思います。

理由2 コードの使い回し、全体を考えたコーディングがしやすくなる

自分自身を振り返ってみると、CSSをはじめたばかりの頃は、目先のコードに追われて全体を考えずにコーディングしていました。(今も割とそうですがorz)
SCSSを使うということは、@extendなどコードを使い回して効率よく記述ことができるようなります。それは、デザインやサイト構成を把握した上で俯瞰的にコーディングできなと、実現できません。そういった考え方を導入しやすくなるというのは、とても良い事です。

理由3 ルーチン的にできる作業をやらなくてすむ

CSSの習得レベルに関わらず、これが一番大きな理由かもしれません。例えばスプライトとか、いちいち手作業でやっていたら、かなり時間を消費してしまう様な事も、CSCCを使えば、一瞬で実現されます。
それで空いた時間を理由2のような構成を考える時間に当てたり、CSSの表現方法を研究する時間にあてたりできます。
「時間」は有限で、与えられた仕事には「納期」があるわけで、その限られた時間を有効に使うにはやはり、頭を使うべき所に時間をかけるしかないです。
SCSSを使えば、それが実現できると思います。そうゆう意味では、CSSの習得レベルに関わらず、コーディングをしている人は積極的に導入すべきではないかと思っています。

で、最近見つけたPreprosというコンパイルツールがすごくいい感じだったので、おすすめです。
prepros
まず、おしゃれすぎます。
最近流行のフラットな感じです。

でも、このPreprosただのおしゃれアプリではありません。

ドラッグアンドドロップで深い階層も検知してくれる

これはいいっす。
僕の開発環境だと、ブログのテーマが並立しているのですが、従来のコンパイルアプリだと、それぞれプロジェクト定義をしなければならなくて、とても面倒でした。

このPreprosは、一発で、深い階層のSCSSファイルも認識してくれるので、管理が楽になりました。

JSのミニファイ化

jsファイルも計量化してくれます。
…あまり、大規模なjsファイルを書く事はありませんが、モバイル系とかだと、必要ですよね。

画像の圧縮

画像も圧縮してくれます。
これはいいっす。
今までは、web系のツールを利用していましたが、アプリで対応できると処理が楽です。

こんな感じで、よさげなツールでございます。

CSSコーディングの新しい概念 BEMなる考え方について

ふと、調べものをしていたら、海の向こう側では「BEM」なる考え方が流行っているようですので、少し調べてみました。

BEMとは

CSSなどを記述する時の考え方の一つで、クラス名に意味を持たせて、識別性や独立性を高めてくれます。

具体的には

Block:上部階層の構成物、固まり
Element:Blockの下部要素、Blockを構成する要素
Modifier:BlockやElementのバージョン違い

の略になっています。

具体的には、コーディングするページを小さな部品(block)に分解して、さらにそのブロックを小さな要素(elemnt)に分解します。
それぞれに固有のクラスを付けて管理しますが、その時にblock-elemetの親子関係がわかるように

<div class="header">
 <div class="header--left">
  <img src="logo.jpg">
 </div>
 <div class="header--right">
  <ul class="header--navi">
   <li>item1</li>
   <li>item2</li>
   <li>item3</li>
  </ul>
 </div>
</div>

block–elementというように書きます。

つまり、boxとかblueTextとか中途半端な命名はだめってことですね。

記述のルール

ここでハイフンが2重になっているのに注目してください。
ハイフンの使い方にルールを付けていて
一つのハイフンは、同一の単語の可読性を高めるために使用します。
例)afternoon-tea

二つのハイフンは、blockとelement、Modifierを区別するために使用します。
例)header–right

詳しくは、こちらのサイトに載っていますので、ご覧いただけばいいかと思います。
http://bem.info/

感想というかまとめ

意訳をしながら読んでみて、なるほどなぁと思いました。
依然、ブログでも書きましたが、破綻しにくいCSSの設計ってコーディングする人間にとって、永遠の悩みです。
ガチガチにルールを決めれば破綻しずらくなるのかもしれませんが、逆に自由度が損なわれて迅速なコーディングができない・・・といった矛盾が発生してしまったりしています。

BEMは、概念的な事だと思いますので、比較的導入しやすいと思いますし、何よりコードの可読性、意味付けが簡単できること、そしてBEMを導入するには、きちんとデザインを咀嚼して、考えながらコーディングしなければならいということに大きな意味があると思います。

個人的にいつも反省しているのが、時間に追われて、とりあえずやっちゃえ的に作業していて、その場しのぎのコーディングが結構あるということです。
小規模サイトで、作りっぱなしだったら、それでもいいかもしれませんが、後々で複数人によってメンテナンスをするような場合は、ダメです。

OOCSSなんかにも通じる考え方だと思います。
基本、クラスだけで記述していくので、メンテナンス性だけじゃなく、パフォーマンス的にもメリットがありそうですね。

ただ、しっかり設計しながらコーディングしないとコード量が肥大してしまう可能性はありますけど・・・

もう少し詳しく勉強して、社内でも導入できるようにまとめて行きたいと思います。

今更聞けないCSSの基本【継承編】

ちょっと思うことがあって、基礎に立ち返ってCSSの基本的なことをまとめたいと思います。
できるだけ、普段使っているCSSの知識を自分の言葉で書きますが、これまで勉強してきたなかで読んだ参考本とかwebサイトの情報に類似している場合があるかもしれません。ご指摘いただければ修正しますので、よろしくお願いします。

はじめに

そもそもなんでこんな事を書こうと思ったかというと
ネタがないから
ではなくて、web制作をしている上で、CSSは必須な項目ですが、他の言語(CSSを言語と表現していいかはわかりませんが)と比べて、学習コストが低い分、誰でもできてしまって結果的に制作物がカオスに・・・という場面を多くみてきたからです。(もちろん、自分も含めて)
「ゴニョゴニョ適当に書いたらそれなりに表示されたからいいや」ってのがすごく多いです。
でも、それじゃいけません。
ちょうど、近いうちにこの辺の話を社内でしなきゃいけなくなりそうなので、自分用にまとめておこうと思ったわけです。

というわけで、数回に分けて、CSSの基礎的なことをまとめて見たいと思います。
(シリーズ物苦手なんで、途中でやめちゃうかもしれないけど)

継承について

いきなり堅い話ですが・・・CSSを語る上で一番重要なことです。
これをしっかり理解できてから、「なんでスタイルが効かないんだよ」ってのが、大幅に減りました。つまりは、余計なことを考えずに、スラスラと書けるようになって、それは時間コスト削減にもつながる。それくらい、大切な事だと思います。

CSSはCascading Style Sheetsの略だというのはご存知だと思いますが、このCascading(つまり上段から流れる瀧のようなもの)が継承という意味になります。CSSでは親要素からスタイル情報を受け継いで表示されます。

例)

<html>
<body>
 <p>ホゲ</p>
</body>
</html>
body {
 color:red;
}

DEMO

pタグには何もスタイルがついていないですが、文字は赤く表示されます。
それは、上部階層であるbodyにスタイルがついているからです。

では、次のような場合はどうなるでしょうか?

body {
 color:red;
}
p{
 color:blue;
}
<html>
<body>
 <p>ホゲ</p>
</body>
</html>

DEMO

この場合、後から記述したスタイルが優先されますので、文字は青くなります。
ただし、何でも後から書けばいいかというとそうゆうわけではなく、セレクタの固有性に基いた計算によって適用されるスタイルが決まります。

具体的にいうと、セレクタにはそれぞれ優先順位を計算するための数値が設定されていて、その合計値が大きいセレクタの指定が最優先されるということです。

優先順位を計算するための数値
1.セレクタに含まれる要素・疑似要素1つを1とする
2.セレクタに含まれる属性・疑似クラス1つを10とする
3.セレクタに含まれるid属性1つを100とする
4.style属性による指定があれば1000とする

例えば

p#hoge {
 color:red;
}
p {
 color:blue;
}

この場合、
p#hoge=[要素属性(1)+id属性(100)]= 101
p =[要素属性(1)]=1
となりますので、たとえ

p {
 color:blue;
}

を最後に書いても、セレクタの固有性の計算結果の数値が大きい「p#hoge」のスタイルが適用されます。

DEMO

また、「どこ」に書いてあるかという事も重要な要素になってきます。

スタイル記述場所による優先順位

スタイルを書くことができる場所は、
・外部スタイル
・headタグ内(styleタグ内)
・要素に直接(style属性)
とありますが、

要素に直接>headタグ内>外部スタイル

という順で優先されます。

デモでは、外部スタイル(黄)、styleタグ(青)、style属性(赤)と文字色を指定しています。当然、style属性が優先されるので、文字は赤くなります。
DEMO

ここで、注意しなければならないのが、style属性は別として、セレクタをかなり上の要素から記述すると、それだけ優先度が高くなるから、安心じゃね?ってのは危険ですということです。
#hoge ul#menu li.menuItem01 a
みたいな指定をすれば、確かに確実に絞り込めます。
しかし、メンテナンス性はどうなりますか?ulの場所が変わってしまったら、cssの記述も書き換えなければなりません。そういった先を見越した設計が必要じゃないかと思います。

まとめ

基本的にcssは上から順番に実行されるので、下の方に書かれたスタイルが優先される。
ただし、セレクタの固有性によって優先性が増す。
そのルールをきちんと押さえておけば、スマートなcssの記述ができるようになる思う。

いわゆるポップ本、これかなり勉強になります。社内の勉強用にも使っています。はい。

web制作現場の悩みの種。破綻しにくいCSSの設計について考えてみた

最近、色々なところでCSSの設計に関する記事を読む機会が増えています。
はやり?このネタに関してはすごく切実な問題で、どうにかしないといけない常々感じていたのでちょうどいい機会なので、すこし考えてみようと思います。

経験的に行なっている事を中心に書きますが、これから導入しようと思うことも合わせて紹介します。参照元も掲載しますのでご了承ください。

まず前提としてジブンB型なのであまりガチガチなルールは、いやです。そんなの決められても困ります。「その辺はニュアンス」って言葉大好きです。(松本の方言でいうところの「なから」ってやつ)なので、ルールといっても方向性的な感じなゆるゆるなものだと思ってください。

矛盾しますが、ルールがあると効率がいいのは事実です。
基本的なことは、ルール化してルーチン的に処理できるのが理想ですよね。

セレクター名って決めるの難しい

CSSを書く上で、けっこうウェイトが大きいのがセレクターの命名ではないかと思います。
最近はなれてきたので、あまり考えずにホイホイと書いていますが、コーディングを始めたころは苦労したのを覚えています。
効率的な管理という面でも、わかりやすいセレクタ名をつけるというのは必須だと思います。
他人でも理解できる=10ヶ月後の自分でも理解できるということですね。
・・・自分で書いてて耳が痛い

そんな訳で、前置きが長くなりましたが、まずありがちなセレクタ名を分類してみます。

フレームとしてのセレクター

例)header main sub footer
レイアウトする上で、基盤となる枠組をつくるためのセレクターです。
主にIDで示される。

少し汎用的な固まりを示すセレクター

例)section item block box
文章のブロックや画像群など、ブロックごとに使い回すようなセレクター。

固有名詞的につかうCSSセレクター

例)hogehogeBnr
CSSスプライトなどを使う時に「このバナー」を特定するためのセレクターです。

ワークフレームとして使うCSSセレクター

例)clearfix mB10
善し悪しは別として、特定のプロパティをセットにしたセレクター。
clearfixとか

jsなどのトリガーとして使うCSSセレクター

特に説明は不要ですね。

ざっと思いつく限りですとこんな感じだと思います。

どうやったら効率よくセレクタ名を決める事ができるか?

ここでルール付けが必要になってきます。
上記の分類を参考に、フレームや汎用的なブロック、ワークフレームはルール化ができますね。

フレーム containaer(コンテナブロック),header(ヘッダー),
main(メインカラム),sub(サブカラム)
汎用的な固まり section,item,block,box
leftCol(左側のブロック)rightCol(右側のブロック)

※ワークフレームとしてのセレクタは少し意味合いが違うので省略します。

mod組みという考え方

codegridを読んでいて知ったのですが、高津戸さんが提唱するCSSの書き方なのですが、CSSを設計するときにモジュール(部品)に分けて書いていくという考え方です。
詳しくはcodegridをご覧ください。

mod組でいいなと思ったのが、セレクタの命名が直感的になるんじゃないかということです。
先に紹介したフレームと汎用的なブロックを組み合わせると
main-section header-leftCol のような絞り込まれたセレクターができます。
こうすれば、大規模なサイトを作る時にセレクタの競合が起こる事がすくなくなります。

この考え方はsassを利用したCSSスプライトでも使えます。
sassでのCSSスプライトはスプライトしたい画像名に依存してCSSの記述を書いてくれるのですが、
無計画にファイル名を記述すると、アルファベット順にならんでしまうので書き出されたCSSはかなりカオスになってしまいます。
そこで、モジュール名(フレーム)を接頭詞にして画像のファイル名をつけると、フレーム毎にまとまって書き出されますので、管理しやすくなります。

ワークフレームとしてのCSS

これ最近導入して、かなり便利だと思っています。
どうゆうことかというと、よく使うようなスタイル群を予め定義しておいて、htmlコーディング時にそのクラスを指定するだけでスタイルを適用させるという事です。

例えば、下方向にマージンを10px取りたい場合

<ul class="hoge">
 <li>ほげほげ</li>
</ul>
ul.hoge {
 margin-bottom:10px;
}

と書けばいいのですが、いちいちCSSを書くのはめんどくさい!ので
事前に

.mB10 {
 margin-bottom:10px;
}

と定義しておいて、htmlをコーディングする時に

<ul class="hoge mB10">
 <li>ほげほげ</li>
</ul>

と下方向にマージンを10pxとるクラスを定義するだけでよくなります。予め良く使うスタイルが定義してあれば、いちいちCSSを記述しなくてもすみますので、コーディングのスピードを上げる事ができます。
※あまり定義しすぎると、不要な記述が多くなったり、管理しきれなくなるので、最低限にした方がいいと思います。

命名ルール

少し余談っぽいですが、命名ルールもある程度統一しておいた方がいいかと思います。
たとえば、単語をつなぐ時にキャメルケースにするのか、「-」なのか「_」なのかとか。
※キャメルケースは単語をつなぐ時に後につづく単語の頭文字を大文字にする記述法です。
hogeItem みたいな感じ。

先述のmod組でいうと、確実に2つ以上の単語がつらなりますので、ルール化しておかないと却って分かりにくくなってしまいます。
個人的にはmod組の時は「-」でつないで、それ以外はキャメルケースというルールでやっています。

まとめ

セレクタ周りにしぼってまとめてみましたが、CSSは簡単なようですごく奥が深いと思いますので、他にも改善すべき箇所はたくさんあります。

ウチの環境はわりと小規模なので、コーディングを複数人で行なう事はあまりありませんが、メンテナンスも考えると一人で完結する事はまずありませんし、CSSのコーディングなんてサイト公開したら忘れてしまうものですので・・・

今回考えたルールがどこまで正しいかわかりませんが、余計な事を考えずに効率よく綺麗にかけるように、仕組みを考えていければと思っています。

僕がscssでいいなと思う4つの機能とまとめ

今、絶賛流行中のCSSメタ言語のscssですが、流行りに乗っかってエントリーします。
基本的な使い方は、色んな方が記事にされているので、僕は個人的にいいなと思う機能についてまとめてみます。

extendの方が僕の好みです。

Scss=mixinみたいな流れですが、僕的にはextendの方が実用的だと思っています。
mixinは、cssのプロパティセットを使いまわすための機能です。

@mixin hoge {
 font-size:15px;
 font-weight:bold;
}
.hohohoh {
 @include hoge;
 color:red;
}

コンパイルすると

.hohohoh {
 font-size:15px;
 font-weight:bold;
 color:red;
}

みたいな形で展開されます。

それに対して、extendは既存のセレクタのスタイルを継承してくれる機能です。

.hoge2 {
 font-size:15px;
 font-weight:bold;
}
.hohohoh2 {
 @extend .hoge2;
 color:red;
}

コンパイルすると

.hoge2,.hohohoh2 {
 font-size:15px;
 font-weight:bold;
}
.hohohoh2 {
 color:red;
}

上記の例だと、それほど違いはありませんが、適用させたいセレクタが多い場合、extendを使ったほうが圧倒的に展開後のcssのコード量が減りますし、見通しがよくなります。

scssを知る以前から、clearfixは、extendのような書き方をしていたので、個人的にはコチラのほうが好みです。

リスト これは、ほんと神です。

これだけでも使う価値があります。

.goku-Title {
 background: url(images/goku.jpg) no-repeat 0 0;
}
.gohan-Title {
 background: url(images/gohan.jpg) no-repeat 0 0;
}
.goten-Title {
 background: url(images/goten.jpg) no-repeat 0 0;
}
.chichi-Title {
 background: url(images/chichi.jpg) no-repeat 0 0;
}

こんなような似通ったコードを書かなければいけない時。
めんどくせーなぁとか思いながら、気合で書くしかありませんでしたが、scssのリスト機能を使うと・・・

$gokufamilies:goku,gohan,goten,chichi;

@each $gokufamily in $gokufamilies {
 .#{$gokufamily}-Title {background: url(images/#{$gokufamily}.jpg) no-repeat 0 0;}
}

こんな感じで書くことができます。
これなら、セレクタが増えた時も簡単に増やすことができます。

変数 地味に便利。

リストのところでも使っていますが、scssでは変数を使うことができます。

$hoge:10px;//変数

.item {
 padding:$hoge;
}

コンパイルすると

.item {
 padding:10px;
}

文字列も変数にすることができたり、演算することもできるようです。

関数 そこまでできるか!

特定の処理をまとめて関数として利用することができます。
たとえば、ブロックの幅に合わせて子要素の幅を自動で割り出すとか。

@function getColumnWidth($width, $count) {
  $padding: 10px;
  $columnWidth: floor(($width - ($padding * ($count - 1))) / $count);
  @return $columnWidth;
}
.hogogogog {
     width:getColumnWidth(500px,5);
}

コンパイルすると

.hogogogog {
  width: 92px;
}

via:ドットインストール 

ここまで来ると、もはやプログラミング言語ですね。

まとめ

scssやzen-coedingって、コーディングを効率化するという意味では同じかもしれませんが、根本的に別物だと思っています。Zen-cordingは文法を簡略化して早く書くもの、つまり速記法に近い感覚。
scssはcssの全体像を把握した上で、部分的にまとめることで効率化させるプログラム的なもの。
結局、cssや全体の構成をきちんと把握できていないと、破綻してしまうのかなと思いました。
逆にいえば、scssを使うことで、全体像を考えながらその場しのぎでないcssを書くことができるのかもしれませんが。

実際に実務では導入するにはもう少し検証が必要かな~と思っていますが(運用面のルールとか)、すごく楽しいのでしっかり覚えて行きたいです。

font-sizeのあれこれ

cssのかなりマニアックな話題です。

A List Apart: Articles: Learning to Love the Boring Bits of CSS というブログに書かれていたのですが、font-sizeを指定する場合、「px」で指定するとIEでフォントサイズが固定されてしまうという弊害があるので、「%」や「em」で指定するのが一般的です。

ちなみにemとは親要素のfont-sizeを1としたサイズです。
例えば、該当するブロックの親要素が14pxの場合 1em=14pxとなります。

個人的には、yui-fontというyahoo!が提供しているフォントサイズを特定の「%」で指定することで対応したpx単位のサイズを表現できるというライブラリを使っています。

「em」で指定する場合は、親要素のfont-sizeを62.5%と指定する事でデフォルトのフォントサイズを10px相当にすることができるので、14pxにしたければ フォントサイズを1.4と指定してあげればよい事になります。

html {
     font-size:62.6%;
}
p {
     font-size:1.4em;
}

ここからが、問題なのですが、フォントサイズが入れ子になっていて、一部だけ大きく表示したい場合

例えば、

<p>「ではみなさんは、そういうふうに川だと云われたり、
<span>乳の流れたあと</span>だと云われたりしていた
このぼんやりと白いものがほんとうは何かご承知ですか。」
先生は、黒板に吊した大きな黒い星座の図の、上から下へ
白くけぶった銀河帯のようなところを指しながら、
みんなに問をかけました。</p>
p {
     font-size:1.4em;
}
p span {
     font-size:1.8em;
}

spanの部分だけ18pxにしたいのですが、実際には
1.4 × 1.8 = 2.52 25px相当になってしまいます。
これは、emが親要素のフォントサイズを基準にしているためで、spanのフォントサイズは1.4em=14pxなので
14pxの1.8倍という数値になってしまうからです。

困ります。

そこで登場するのが「rem」という単位です。これはcss3から登場した単位になりますので、一部のブラウザでは対応していないのですが、「root」+「em」という意味でroot要素つまりhtml要素のフォントサイズを継承してemと同じ計算ができる単位になります。

先ほどの例でいうとspan要素を1.8remと指定してあげれば、
root要素(10px)×1.8=18pxというフォントサイズになる訳です。

html {
     font-size:62.5%;
}
p {
     font-size:1.4rem;
}
p span {
     font-size:1.8rem;
}

DEMO

あまり華やかなコトではないので、スルーしがちですが、きちんと理解しておきたい部分ですね。