Web屋のーりー

ウェブ作ったり、デザインしたり、広告についてかんがえるブログ。

powered by 36℃社

  • twitter
  • Facebook
  • Linked in
  • RSS

初心者さん向け情報の詰まった記事です。デザインのイロハをご紹介

かわいいデザイン・優れたデザイン、広告、コピーライティング

その他のお役立ち情報、たまにおもしろ情報も?

CSSコーディングのお仕事を理想に近づけたい。CSS Nite LP39 イベントレポート

このエントリーをはてなブックマークに追加
Pocket

最近、CSSの詳細度が深いと夜も眠れなくなる私です。こんにちは。
もちろん、今日はHTMLとCSSの話になるわけなんですが、今日はCSS3とかCSS4とかの、「こんなプロパティがあるんだぜぃ」といった話じゃあないんです。角丸とかそういうのじゃなくてですね、どっちかというとセレクタのほうの話です。

皆さん、CSSでセレクタを付けたいとき、どうします? idにしますか? classにしますか?
「え? どっちかって、どっちでもいいでしょ」と答える方、いらっしゃいますよね、皆さんの部下や、新人さんなどで。

答えはもちろん、classです。idはほぼ使わないのです。

いちおう簡単に解説しておきますと、idでCSSを書くと、idでは「詳細度」という、スタイルが適用されるときに優先順位を決めているもの、がclassよりも強くなってしまって、classのみで書いているスタイルが、idで書いたときのスタイルに打ち消されちゃうんですよ。
まだfire bugとかがなかったころや、新人だったころ。「なんでCSSが効かないんだムキー」って経験、必ずあるでしょう。
いやむしろ、これを読んでいるあなたが、いまそういった経験をされているまっただ中かもしれません。
そもそも「classで書け、なんて知らなかった……」と心配になっているかもしれません。

でも、大丈夫です!

CSS Nite LP39「Coder’s High 2015」という、Web制作に関するセミナーイベントで紹介されていた数々の知識をまとめれば、なんとかなるのです、きっと。

というわけで、Web制作界隈の方ならだいたい知ってるセミナーイベント、CSS Niteのイベントレポートをお送りします。今回はCSSとHTMLの理想と現実、といったような内容。
各セッションで個人的に気になったところを取り上げていきますよ!

CSS設計の理想と現実

まずはサイバーエージェント谷 拓樹さんのセッションです。
上記で書いた「詳細度」をどうコントロールするか、そしてそれを含めて、CSSをどのように設計したらいいのか、という内容。

HTMLの設計と違って、CSSの設計というと何だろう、ってなる人もいるでしょうが、誤解を恐れず簡潔に言えば、ある程度ルールを決めてCSSを書く、ということですね。

じゃあ、設計のためのルールをぜんぶ一から作らないといけないのか、というとそんなことはなく、すでに世界の素晴らしい開発者の皆様が考えた、CSSの設計手法をまとめたアイディアがこの世の中にはあるんです。
有名なものとしては以下のものなどがあるそうですね。

  • OOCSS
  • SMACSS
  • BEM
  • FLOCSS

上記の中でも、FLOCSSは登壇者の谷さんが作成しているガイドラインだそうなので、手を出しやすいのではないでしょうか。

もちろん、いきなり急に、「明日からBEM使おう」とはならないです。ならないですよね(笑)
でも、もし今まで何も考えずにCSSを書いていたとしたら、それをちょっと変えるだけでも違ってくるんです。

たとえば、以下の2つを意識してみるだけでも「メンテナブル」なCSSの第一歩ですから。

  • idは使わない (idを使う合理的な理由がない限り、使わない)
  • セレクタを深くしすぎない

最初はやりやすいところから着手していって、どこかのタイミングで設計手法を取り入れればよいわけです。

それから、谷さんのセッションの中で、個人的に「次の案件からやろう!」と思ったのは、
「ボキャブラリーガイドを作るといい」という点でした。
ボタンのスタイルを作るときにbtnといった名前を使うのはよくやりますが、そういった名前のリストを作っておく、ということです。

セレクタ名や、ファイル名、画像の名前って、単に英訳した単語を入れればいいのか、短縮形にするのか、頭の3文字にするのか、日本語の名称をローマ字読みにするのか……などなど、一人で作るとしても迷うわけですよ。

これはもう、次回から取り組んでみたいです!

こちら、谷さんが書いている、このセッション内容の下敷きにもなっていて参考になる書籍です!

理想のCSSフレームワークを探して

2番めは、アップルップル森田 霞さんのセッション。

アップルップルさんといえば、a-blog cmsというCMS開発で有名で、その管理画面・公式テーマのコーディングをされている中の人が森田さんです。
森田さんはどうやら、CSSフレームワーク大好きっ子(?)みたいでして、いろいろなCSSフレームワークを紹介してくれましたが、私が使ったことあるのはBootstrapしかないので、他のも触ってみないといけないですよね、という気持ちになるセッションでした。

内容に入る前に、そもそも「CSSフレームワークって何ぞや?」という話をちらっとしておきましょう。
最初からパーツやレイアウトができていて、htmlにセレクタを与えてあげるだけで整うパーツ集、といったイメージでしょうか。この説明で、わからない人に理解してもらえるか自信ないですが……。

フレームワークを導入して、セレクタを指定すれば、それだけでグリッドレイアウトができたり、整ったボタンのスタイルができるんです。
でも、そのスタイルは、BootstrapならBootstrapの開発者さんが作ったスタイルで、汎用的なものなので、どうしても限界があるんです。

それらについて、森田さんは3つの不満、として表現されていました。

  • 不満1:似てきちゃう
  • 不満2:コードが増大
  • 不満3:HTMLに依存

どれも、既にCSSフレームワークを利用されている方なら思い当たるフシがあるでしょう。

それらの不満に対する答えは、実は完璧な答えがなくて、森田さんも「完璧なフレームワークはない」とおっしゃっていました。
それでもうまく付き合う方法はあって、たとえばレイアウトのみ、グリッドシステム部分だけを使う、とか、
UIのパーツだけを使う、などでしょう。

また、案件ごとにどこまでCSSフレームワークのスタイルを適用するのか考えるのも大事ということで。

  • 中・大規模案件では、グリッドなど骨組みだけ採用
  • 特急、システム案件ではそのまま使ってみる

さらに、UIパーツとグリッドレイアウトでそれぞれ別のCSSフレームワークを併用する、というキメラ案も紹介されていました。
私も、機会があればこの方法は採用してみたいです。

それから、bootstrapのDL時に機能を限定してDLすることができる、ということも森田さんは紹介されていたので、これも次の案件で試してみたいです。

5分でゼロからテストサイトまで立ち上げます!

こもり まさあきさんのセッション。LT枠。10分しかないとのこと!

もし自分が5分(解説しながら10分)で上記内容をやれ、と言われたら確実に立ち往生ですけれども、CSS Niteの公式情報を引用すると、以下のとおり。

“スタティック・サイト・ジェネレータを使って、たった5分で外部から閲覧可能なテストサイトを公開します。”

いや、ほんとに10分でやっていました。

こもりさんの詳しい動き、何をやっていたかなど、会場で見ていた人の中には、たぶんちんぷんかんぷんだった方も多かったのではないかな、と。
私も半分くらいしかわからなかったのですが、実はその内容は、こもりさんが出している電子書籍の環境構築本Development Environments for Web Designersでフォローされている、とのこと。

それだけじゃなくて、この次のピクセルグリッドのお三方のセッションで取り上げられていたタスクランナーの導入方法も、こもりさんの本ではカバーされています。

じゃあその環境構築本が、デザイナー・ディレクターを含めた制作者全員に役立つかというと、そうではないでしょう。
今回のCSS Niteは、じつはコーダさんじゃなくてデザイナーさんでも役立つというか、「むしろデザイナーさんにこそ聞いてほしい」というような内容も多かったのですが、こもりさんのセッションに関してはフロントエンド、ド直球といった感じ。
少なくとも、自分の肩書が「フロントエンド」の方は、購入されて損はないのかなと感じます。

その本を読むことで、10分でゼロからテストサイトまで立ち上げられるかどうかの保証はできかねます。

ビルドツールはじめの一歩

続いては、ここ1年くらいで急激に存在感を増している、ビルドツールの導入方法を丁寧に紹介してくれた、ピクセルグリッドの皆さんのセッション。
宇野 陽太さん、坂巻 翔大郎さん、小山田 晃浩さんの3名です。

ビルドツールの難しそうなところは、まず用語がわからないし、小規模の案件だと導入したところであまり高速化できなさそう(な錯覚がある)だし、もし環境構築がうまくいかない場合に誰にも聞けないことも多いし。

……と、いろいろハードルがあるわけですが、そんな私のような人にぴったりのセッションだったわけでして、しかもWinでの導入についてもカバーされていたところが素晴らしい。

もちろん内容については会場参加者(とフォローアップ参加者)の特権ではあるんですけれども、(またまたご紹介です)ピクセルグリッドさんの定期購読で読めるCodeGridの記事の連載として、gulpの導入方法についてがあるそうですので、そちらをぜひ。

ここからはセッション内容から離れて、個人的な意見になりますが、「ビルドツール(&タスクランナー)という名前だけは知っている」「gulp, gruntとか最近聞いた」という方はぜひ、そもそも何が出来るの? というのをまずは知ってほしいところです。

できることはいろいろあるそうなんですが、例えば以下のことができるそうです。

  • SASSコンパイル
  • JS圧縮
  • コードの連結
  • CSSスプライト
  • プロジェクトのディレクトリを日付をつけてzipで固める

もうちょっとできることを知りたい場合はこちらを参照。

「できること」を知ってみて、「これはやってみたい!」と思えればしめたもの、って感じで。
CLI(コマンドライン)、いわゆる黒い画面のターミナルとかのシェルで操作せずとも導入できるみたいですからね。
黒い画面のことも覚えて、gulpも覚えて、sassも覚えて……とかになってしまうと、覚えることとしては供給過多なわけですよ。もちろん覚えていけば何かと役に立つんですけれども、まずは小さいところから一歩進めばいいわけです。

だからこそ、はじめの一歩がだいじということで!

music.jpのリファクタリング before/after

残すところあと2セッション、最後から2番めは、まぼろしの小林 信次さん(プロジェクトの受注側)と、エムティーアイ宮地 存さん(発注側)のセッションです。

内容は、music.jpさんのリニューアルを受注側として担当されたまぼろしの小林さんと、発注側としてとりまとめた宮地さんのお二人が、どのように改善したか、といった、普段絶対に外に出てこないようなお話。

規模の大きいサイトさんですし、それも単にリニューアルというだけでなく、リファクタリング――つまり、CSSやHTMLのコードの中身を改善するプロジェクトに取り組まれたそうです。

ある程度の期間サイトが運用されていると、継ぎ足しのコードが増えていくわけです。
それは仕方ないことなんでしょうが、それをどうにかできないか、ということで始まったプロジェクトだそうで、KPIは工数削減などを中心に据えたそうです。
なかなか社内合意は難しかったんじゃないか、というのは想像に難くないですけれども、そこを合意に至り、結果としてかなりの削減に至ったそうです。

このプロジェクトでポイントになったは、サイトパーツのコンポーネント化でしょう。
最初のセッションの谷さんの内容や、CSSフレームワークを扱ったセッションの森田さんの内容、そしてこの次のセッションの高津戸さんの内容にも出てくる「コンポーネント化」、要は部品化ですけれども、いかにいい意味で「使いまわせる」コンポーネントを作れるかがだいじです。

そして、そのためにはデザイナーとの協業が欠かせないわけです。その意味では、デザインとフロントエンドの職域は重なってきていますよね。

柔軟なコンポーネント設計のためのCSS

最後のセッションは、ピクセルグリッドの高津戸 壮さん。何度か出てきている、コンポーネント設計についての内容でした。

まず出てきた単語が、粒度。りゅーど。ツブのことです。
この単語は、どのくらいの大きさなのか、みたいなときに使うんですが、開発の現場ではたまに出てきますよね。
で、CSSコンポーネントも粒度であらわせるし、設計をするにはそれを決めないといけないのです。

でもこれがまた、やったら難しいんですよ。
たとえばボタン一個なのか、ボタングループなのか、ナビゲーション全体としてのコンポーネントなのか、みたいなのはすべて粒度が違うわけです。
ですので、作る際にはあがってきたデザインを「どこがUIコンポーネントとして切り取れるか」といった具合でとらえる思考が必要なのかなぁと感じるのですが、それでも何をコンポーネント化すればいいのか、を毎回考えていたらたいへんですよね。

その際にヒントになるのが、「3回出てきたらコンポーネント化」というアイディアです。
この日の最初のセッション、谷さんも言及していた考え方で、元ネタは「Refactoring」というプログラミングの書籍で出てきた、Rule of threeだそうです。
コンポーネント化のタイミングって決めにくいんですが、それを3回めでやろう、というルールに従うならばわかりやすいですよね。

高津戸さんのセッションでは、かなり余白に注目した内容が盛り込まれていて、そのコンポーネントの中に含まれている要素が、一部取り除かれたときも正しく余白がでるようにCSSを書く、ということを話されていました。
たとえば見出しと画像が上下にあって、その2つを枠が囲っているデザインのコンポーネントのとき、上にある見出しのmargin-bottomとしてCSSを書く、といった例です。
これは、もし上の見出しがなくなったとしても、画像のみでも枠の余白が変わらないスタイルになります。もし逆に、画像の上にmargin-topで設定してしまうと、画像のみのときに枠の上部の余白が増えてしまうわけですね。

そういった余白に注目したいくつものパターンを紹介してくれていたところが、けっこう好評価だったセッションでした。

まとめ

まずは、画像もなんにもない、この記事をここまで読んでくれてありがとうございます!

全然、まとめじゃなくて感想でしかないんですけど。いろいろ考えさせられたんですが、そのきっかけの一つとして、今回聴講をご一緒していた盟友でもある制作者さんが「デザイナーがデザインするときも、粒度を考えるべきなんじゃないかと思う」って言ってたのが、そうだよなぁと思ったのです。

それを実現しようとするのが、もしかしたらコーディングにおける理想で、現実としてだいじなのがお互い歩み寄ったり、お互いの作業領域を良い意味で越えていくことなのかなと思うわけでした。

コメントする

ページの先頭に戻る