HAKASHUN.net

この１週間、サイト制作のためにCSSをコーディングしていました。

奇麗なCSSとは何か？

そもそも、奇麗なCSSの条件とは何か、改めて整理しなくてはいけません。
Googleでは、「Google HTML /CSS Style Guide」（※リンク先は和訳された方のサイト）という、コーディングガイドラインがあります。
そこでは、

IDとクラス名にはちゃんと意味の分かる名前を使う

要素の目的や役割を反映した名前を付ける。意味の分かる範囲でできるだけ短いIDとクラス名を使う。

IDとクラス名にタイプセレクタは記述しない。

ul#example {} => #example {}

可能な限りショートハンドでプロパティを書く。

font: 100%/1.6 palatino, georgia, serif;のように、１回でまとめてプロパティを書く

IDやクラス名の別々の単語はハイフンで繋ぐ。IDやクラス名には固有の接頭辞を付ける。

#video-id {}

すべてのプロパティ名の終端にはコロンの後にスペースを入れること。

display:none; => display: none;

など、細かなコーディングのルールが定められています。
奇麗なCSSとは、他のプログラミング言語と同様に、保守性の高さ・パフォーマンス・動作の正確さ・無駄な部分の排除といった要素が満たされているものみたいです。
加えて、一貫したルールを持たせて記述することが大切ということも、このガイドラインから感じることができます。
個人で奇麗なCSSの定義をすることもできますが、GoogleやFacebook、Twitterなどのガイドラインを見習うことがスマートだと思います。
欲を言えば、そのルールがなぜそのように決められているのか理解することが大切だと思います。

Twitter社製ツール、『RECESS』という解決方法

奇麗なCSSを書くためのルールは理解しても、それに縛られるが故にコーディングのスピードが下がってしまうと思います。
Twitter社が公開しているツール『RECESS』は、作成した煩雑なCSSを奇麗なCSSに再出力してくれるツールです。

コンパイル前とコンパイル後｜クリックして拡大

このツールを使って指定したCSSをコンパイルすると、画像のようにプロパティの順番が規則通りになったり、コードの可視性が向上します。

間違っている部分を丁寧に指摘してくれる

また、命名規則やプロパティの順番が間違っている場合など（画像の場合は、#goToTopを#go_to_topにしなくてはならない）に、警告を出してくれます。
最終的に瞬時にコードを整形してくれるツールがあると、スピードを落とさずに質の高いものを実現できるので大変心強いです。
RECESSでは、適さない命名などのチェックもしてくれるので、チェッカーとして用いることもできます。

RECESSのインストール

RECESSを使うために、node.jsとnpmをインストールする必要があります。
昔は、両方とも別々にターミナルでコマンドを打ってインストールしなくてはなりませんでしたが、現在はnode.jsの公式ページにインストーラがあるので、自分のOSを選択してダウンロードすれば簡単にインストールできます。npmも同時にインストールされるので、RECESSをインストールするための環境構築は一瞬でできると思います。

いよいよ、RECESSのインストールをします。ターミナルなどで、以下を実行します。

$ sudo npm install recess -g

RECESSインストールの成功時

上記画像のようになれば、インストール完了です。

RECESSを使ってみる

早速RECESSを使って、煩雑なCSSを奇麗にしてもらいます。
cd コマンドで、自分のプロジェクトフォルダに移動して・・・

$cd プロジェクトフォルダへのパス

recessコマンドと共に、コンパイルさせたいcssのパスと出力させたいcssの名前を指定します。

$RECESS コンパイルさせたいcssファイル --compile > 出力cssファイル

RECESSを用いてCSSをコンパイル

これで、指定したファイル名で奇麗になったCSSファイルが出力されます。

出力はさせずに、CSSのチェックを行うときはシンプルに以下を実行します。

$RECESS チェックしたいCSSファイル

RECESSを用いてCSSをチェック

CSSファイル名の適さない部分を色々と指摘してくれます。

最後に

RECESSのgithubページを見ると、その他の使い方も記されています。
RECESSは、lessのコンパイラとしての機能を持っているので、less愛好家の人は今回紹介した以外にもメリットを教授できると思います。

RECESSのおかげで、なんとか人に見せても恥ずかしくないCSSが作れそうです。

CSS拡張メタ言語であるlessを個人制作の中に導入しました。個人的にどのように使っているかを整理したいと思います。
前編では、どのような環境で、どのように使っているのかにフォーカスをあてて綴りたいと思います。

使用している環境

[OS] Mac OS X 10.6.8
[エディタ] Coda http://www.panic.com/jp/coda/
[Coda プラグイン] less用の構文モード https://github.com/monoceroi/LESS.mode
[lessコンパイラ] less.app http://incident57.com/less/

less使用の基本的な流れ

はじめに、lessの利用方法は３つあります。

1. .lessファイルをクライアント側で読み込んでコンパイルする方法
   .lessファイルをjsを用いてパースします。速度的な問題が懸念されます。
2. サーバサイドでコンパイルする方法
   node.jsを利用してコンパイルする方法。nodeを導入するのに若干コストがかかりそうです。
3. ローカルでlessファイルをコンパイルしてcssを生成し、普段通りにcssをサーバにアップする方法
   一番無難な方法です。ローカルで.lessファイルを管理、コンパイルします。.lessファイルが共有できていないと、複数人のプロジェクトで混乱が生じるかもしれません。

個人制作での使用であることから、今回は3の方法でlessを導入、利用することにしました。
以下の画像は、その際のフローを簡単に図にまとめたものです。


[lessファイル] → [CSSファイル]の際にはCSSの書き出し先フォルダを指定しています。
また、関連するlessファイルを予め登録することで、lessファイルが変更、保存された際に自動的にCSSをコンパイルするようにしています。
この仕組みによって、lessファイルを保存した次にブラウザで確認すれば最新のCSSが反映されます。
これまでのCSSコーディングのやり方とほとんど変わらぬ感覚で制作を進めていけるのがポイントだと思います。

ファイル構成など

ファイル構成は、以下の図のようにしています。
最終的に書き出されるCSSは1つですが、実際には機能や構造に合わせて、複数のlessファイルを作っているのがわかると思います。
このようにした意図は、2点あります。

1. 将来的な運用のコストをできるだけ減らす
2. クライアント側の読み込み速度をできるだけ早くする

クライアント側にデメリットを生じることなく、CSSを機能、構造別に管理できるのは、大きな進歩だと感じました。


複数のlessファイルを一つにまとめるための.lessファイル（図の場合は[project.less]）には、以下のような記述がしてあります。


こうすることで、実際にコンパイルが必要な.lessファイルは、project.lessだけでよくなります。
この方法は、NAVERのエンジニアブログ（http://tech.naver.jp/blog/?p=951）でレコメンドされていました。
importしているlessファイルが、パッと見で把握できるように"_"（アンダーバー）をファイル名の頭につけています。

大まかにどのような環境でどうやってlessを使っているのか説明してきました。
後編では、具体的なlessプログラミングについてまとめたいと思います。

無事に大学を卒業し、今春からWebデザイナーとして都内のIT企業に就職しました。
新卒社員として、週末は社内研修合宿に参加し、感じたことや得ることが多かったので、未来の自分のために記事として残したいと思います。

本質から逃げない。

研修では新規事業提案をチームで考え、プレゼンしました。
チームで考えていく中で必要となる技術や知識、姿勢などにおいても様々な学びを得ることができましたが、プレゼン後のフィードバックで「本質から逃げるな」という指摘をされ、ハッとしました。

事業案を考えていく中で、

• 「どうすればお金になるか...」
• 「どうすればユーザが増えるか...」
• 「ターゲットはどこがいいか...」
• 「競合のサービスはこんなのがあって...」

など、なんとなく固まりつつある一つのアイデアのプレゼンに向けて、落ち度のある点や指摘されそうな点をつぶしていく作業に方向性が傾いてしまいました。

もちろん、これらは必ず必要となる議論なのですが、僕たちはこれらを議論してプレゼンできなくもない状態になった上で、最終的に次のような点から再度考え直すことになっていましました。

• 「自分だったら使いたいと思うか」
• 「自分たちが本気になってできるサービスか」
• 「人はなぜサービスを求めるのか」
• 「人は何を幸せと感じるのか」
• 「人はなぜ流行っているサービスを使っているのか」
• 「流行っているサービスを使っている中で、今何を感じているのか」

僕は、「本質から逃げている」という言葉から、以上のような点についてチームで熟慮することが欠けていたのだと感じ、ハッとしました。
本質的な点を熟慮し、方向性や答えを決めて進み始めなかったため、
プレゼンとしてまとまってはいても、どこか気持ちが乗らなかったり、表面的な事柄を寄せ集めたような内容になってしまったのだと思います。

また、事業を提案するからには、自らが身を捧げる心意気でサービスを創り、絶対の自信を持って運営をし続ける覚悟も伝えなくてはいけません。
この点を伝えられなかったのも、結果的に役員の方にGoと言ってもらえなかった理由だと思います。

もう既に数多あるWebサービスの中で、ユーザに新しい体験や感動を与えるサービスを作るためには、本質的な議論をとことんすることが必要不可欠であると強く感じました。

学生から社会人となり１週間ばかりですが、
ここで感じたことを忘れずに努力を重ねていきたいと思います。