前回の記事では、SMACSSの電子書籍をまとめてみました。 CSSスタイルガイドのSMACSSを勉強してみたまとめ
今回は、書籍を読むだけでは理解が深まらないので実際にSMACSSを意識しながらコーディングしてみました。
ランディングページを作ってみる
今回は、題材としてランディングページのコーディングをしてみました。
ランディングページとは、LPと呼ばれたりもするので、広告や検索から訪れるユーザが最初にみるページのことです。
人間関係でも第一印象が大事と言われるように、商品とユーザが初めて出会う場所ですのでサイトのユーザに与える印象の大事な部分を担っています。
今回はSMACSSを意識しながら書いてみて、悩んだところや、よかったところ、SMACCSでは表現しにくいところを知るための題材ですので、それほどユーザに与える印象とかビジネスライクな部分はあまり意識していないです。
というか、私普段からバリバリcss書いていててcssでは誰にも負けません!!
という感じではないので私のコードはあくまでも私のコードで、これを参考にすれば大丈夫!!みたいな絶対的なものでなく、コーディングしてみましたーというようなのものなのでご了承ください。
その点踏まえて、仕上げたページはこちらになります。
おぉ・・・
まぁありがちですね。 サイトは自分が開発してみたいなぁと思っている個人のタスク管理ツールをイメージして作りました。
レイアウトはシングルカラムレイアウトのよく見るランディングページという感じですね。
ログインボタンやサインアップのボタンを押すとフォームが表示されたりするようにはしていますが、完全なるデモページなので、それ以上は進めません。
ご了承ください。
デモページのリンクはこちらです。 GitHubPagesで後悔しているので実際のデモがご覧いただけます。
https://version-1.github.io/smacss-sample/example/default/
ソースはgithubにあげておきました。 https://github.com/version-1/smacss-sample
SMACSSしてみて気づいたこと
- 境界線の引き方が難しい
- moduleのソースが大きくなりがち
- jsをどれくらい使うかでコードが変わりそう
境界線の引き方が難しい
これは単に慣れ次第でもう少し切り分けができるようになるかなとも思うのですが、他のcssの設計手法と同じように線引きが難しいと感じました。
何がレイアウトで何がモジュールなのかというのはやはりコーディングをしていて悩みました。
カルーセルやアコーディオンなど明らかにわかりやすいのは良いのですが、ヘッダーやフッターはどこまでレイアウトのカテゴリで書くべきなのかというのは悩みました。
SMACSSを提唱している原本でもそこまで明確に線引きをしている訳ではないので、あくまでもセマンティック性の維持と保守性という目的から考えたベストエフォートを取っていくしかないのではないでしょうか。
結果的にはレイアウトは最低限の大枠に留めて、ヘッダーやフッターの中のスタイルのほとんどは、モジュールで定義しました。
モジュールのソースが大きなくなりがち
LPをコーディングした結果以下のような構成になりました。
みてわかるようにSMACSSのカテゴリでシンプルに分類しています。 モジュールが全体の80%くらいになりそうですね。。
もう少し大きいシステムになると管理画面とユーザの画面でスタイルを分けたりする必要があるので、管理者、ユーザ、共通、のような形で分けて各セクションごとにベース、レイアウト、モジュール・・・のように分けてしまう方法もありかもしれません。
今回に関してはLPのみのコーディングでしたので、入れ子にせずフラットに分割しました。
スクショみてもわかるようにレイアウトは大まかなところ、モジュールは細かいところというような形で分担してしまったので、モジュールのコードが占める割合が大きくなっています。
大きくなること自体が悪いわけではないのですが、大きい分その中に冗長なコードが含まれているのではという懸念もあるので、ちょと不安になりました。
コードを書いていると
「これ、ステートじゃないよな」
「レイアウトでもないしな」
「じゃあモジュールか」
という感じで多くのコードがモジュールに流れつきましたね。
まぁここは割合の問題というよりは、あくまでもセマンティックで重複のないコードを目指す上での問題なのでそれらを鑑みて 「どうすれば一見で理解できて、整理されたコードになるのか」 というのを考えながらリファクタして答えを見つけていいかないといけません。
jsをどれくらい使うかでコードが変わりそう
今回一応JQueryも使っているのですが、本格的にJQueryでクラスを当てたり外したりということはせず、いくつかのアニメーションを極力cssで実現できるようにしました。
modalに関しては、modal-cssを使ったので、jsをほとんど自分で書くことはなく、カルーセルでもslick.jsでslickの関数呼び出し、アコーディオンでのクラスの割り当てに簡単にjs使うくらいでした。
JQueryをもっとバリバリ書いていくとよりステートコードが増えていきそうです。
ランディングページだけなのであまりJS書かなくて済んでいますが、もう少しページが増えて大規模になってくるとJQueryも必要になってきそうなので、実際の現場ではもう少し、ステートのコードの割合は増えそうな気がしています。
工夫したこと
簡単に今回自分なりに工夫したことを書くと以下になります。
- テーマの層が有効に使えるようにした。
- アコーディオンやボーダーのアニメーションなどが極力HTMLに依存しないようにした。
テーマの層が有効に使えるようにした
SMACSSの原本によるとテーマの層はプロジェクトによって存在しない場合があるそうですが、テーマはサイトの見た目の変更をユーザに委ねる場合などで使われるようです。
ようは、見た目の変更をユーザの好みに合わせてできるようにしますよということです。
今回上のディレクトリ構造の写真によると_variable.scssというファイルと、theme/_default.scssというファイルがあります。
これが何をやっているかというと、 _variable.scssでサイトで使う色やフォント、フォントのサイズなどを変数を使って定義しています。
さらに今回は、_variable.scssでは主に、ユーザがいじれないような変数を定義して、theme下のファイルで代表的な色をユーザの好みに合わせて色を変更できるようにしました。
スクショだと、theme下に4つのファイルがありますが、それぞれサイトの色を変更できるテーマファイルになっていて読み込むファイルを変更することで、サイト内で使われる色を変更できます。
下記の例では、default.scssを読み込んでいます。
@import 'theme/default';
// @import 'theme/theme1';
// @import 'theme/theme2';
// @import 'theme/theme3';
/* bg-color{{{ */
$primary-bg-color: map-get($color-map,site-base-white-color);
$secondary-bg-color: map-get($color-map,site-quaternary-color);
・
・
< 略 >
それぞれの例は、下記URLで確認できます。
モジュールのアニメーションがHTMLに依存しないようにした
アコーディオンを今回自前で実装しました。がアコーディオンのアニメーションをこのページ二箇所で使えるように実装しました。
一つはFAQのコーナーで、一つは画面幅が狭い時のメニューです。
どちらも、隠れていたオブジェクトが表示される際にアコーディオンが開くのをイメージした形で実装されています。
また、hover（マウスオーバー）した際に発火する下線のアニメーションもhtmlにクラスを追加するだけで、アニメーションが実現できるようにしました。
これらに関してどのアニメーションも要素タグを使っていないので、HTMLと疎結合な形でCSSを実装することができました。
まとめ
ここまで色々とまとめましたが、正直まだSMACSSはわからないです。。
SMACSSは意識しつつもOOCSSも意識して構造と見た目は分離した方がいいのか やこれは本当にモジュールとして定義していいのか
などなど疑問はつきません。
まぁどのスタイルガイドを採用するにせよ、セマンティックで変更に強い重複のない設計が求められるとは思うのですが、これは最初に実装してみた後に徐々に変更を加えてみると
「このコード変更するときにやたらコード書くな」
みたいな違和感を感じてコードのよくない部分に気づける気がしています。
実装完了した時は完璧に実装できているように見えるけど、実際に拡張してみたりのちの変更に対応してみるといかに最初の設計の弱い部分が見えてくるのでしょう。
今回紹介したコードも暫定的なものなので、これらを差し引いてみて頂けると嬉しいです。 今回は設計の話がメインでしたが、SMACSSで書いてみるに当たって新たに学んだコンポーネントのつくり方なども紹介して行ければと思います!!
では
