CSSコーディングのお仕事を理想に近づけたい。524初心者さん向け情報の詰まった記事です。デザインのイロハをご紹介かわいいデザイン・優れたデザイン、広告、コピーライティングその他のお役立ち情報、たまにおもしろ情報も?CSSコーディングのお仕事を理想に近づけたい。524最近、CSSの詳細度が深いと夜も眠れなくなる私です。今日はHTMLとCSSの話になるわけなんですが、今日はCSS3とかCSS4とかの、「こんなプロパティがあるんだぜぃ」といった話じゃあないんです。角丸とかそういうのじゃなくてですね、どっちかというとセレクタのほうの話です。どっちかって、どっちでもいいでしょ」と答える方、いらっしゃいますよね、皆さんの部下や、新人さんなどで。答えはもちろん、classです。idはほぼ使わないのです。いちおう簡単に解説しておきますと、idでCSSを書くと、idでは「詳細度」という、スタイルが適用されるときに優先順位を決めているもの、がclassよりも強くなってしまって、classのみで書いているスタイルが、idで書いたときのスタイルに打ち消されちゃうんですよ。bugとかがなかったころや、新人だったころ。「なんでCSSが効かないんだムキー」って経験、必ずあるでしょう。いやむしろ、これを読んでいるあなたが、いまそういった経験をされているまっただ中かもしれません。そもそも「classで書け、なんて知らなかった......」と心配になっているかもしれません。2015」という、Web制作に関するセミナーイベントで紹介されていた数々の知識をまとめれば、なんとかなるのです、きっと。Niteのイベントレポートをお送りします。今回はCSSとHTMLの理想と現実、といったような内容。拓樹さんのセッションです。上記で書いた「詳細度」をどうコントロールするか、そしてそれを含めて、CSSをどのように設計したらいいのか、という内容。HTMLの設計と違って、CSSの設計というと何だろう、ってなる人もいるでしょうが、誤解を恐れず簡潔に言えば、ある程度ルールを決めてCSSを書く、ということですね。設計のためのルールをぜんぶ一から作らないといけないのか、というとそんなことはなく、すでに世界の素晴らしい開発者の皆様が考えた、CSSの設計手法をまとめたアイディアがこの世の中にはあるんです。有名なものとしては以下のものなどがあるそうですね。OOCSSSMACSSBEMFLOCSS上記の中でも、FLOCSSは登壇者の谷さんが作成しているガイドラインだそうなので、手を出しやすいのではないでしょうか。急に、「明日からBEM使おう」とはならないです。ならないですよね(笑)でも、もし今まで何も考えずにCSSを書いていたとしたら、それをちょっと変えるだけでも違ってくるんです。以下の2つを意識してみるだけでも「メンテナブル」なCSSの第一歩ですから。(idを使う合理的な理由がない限り、使わない)セレクタを深くしすぎない最初はやりやすいところから着手していって、どこかのタイミングで設計手法を取り入れればよいわけです。「ボキャブラリーガイドを作るといい」という点でした。ボタンのスタイルを作るときにbtnといった名前を使うのはよくやりますが、そういった名前のリストを作っておく、ということです。セレクタ名や、ファイル名、画像の名前って、単に英訳した単語を入れればいいのか、短縮形にするのか、頭の3文字にするのか、日本語の名称をローマ字読みにするのか......などなど、一人で作るとしても迷うわけですよ。cmsというCMS開発で有名で、その管理画面・公式テーマのコーディングをされている中の人が森田さんです。森田さんはどうやら、CSSフレームワーク大好きっ子(?)みたいでして、いろいろなCSSフレームワークを紹介してくれましたが、私が使ったことあるのはBootstrapしかないので、他のも触ってみないといけないですよね、という気持ちになるセッションでした。内容に入る前に、そもそも「CSSフレームワークって何ぞや?」という話をちらっとしておきましょう。最初からパーツやレイアウトができていて、htmlにセレクタを与えてあげるだけで整うパーツ集、といったイメージでしょうか。この説明で、わからない人に理解してもらえるか自信ないですが......。フレームワークを導入して、セレクタを指定すれば、それだけでグリッドレイアウトができたり、整ったボタンのスタイルができるんです。そのスタイルは、BootstrapならBootstrapの開発者さんが作ったスタイルで、汎用的なものなので、どうしても限界があるんです。それらについて、森田さんは3つの不満、として表現されていました。不満3:HTMLに依存どれも、既にCSSフレームワークを利用されている方なら思い当たるフシがあるでしょう。それらの不満に対する答えは、実は完璧な答えがなくて、森田さんも「完璧なフレームワークはない」とおっしゃっていました。それでもうまく付き合う方法はあって、たとえばレイアウトのみ、グリッドシステム部分だけを使う、とか、UIのパーツだけを使う、などでしょう。案件ごとにどこまでCSSフレームワークのスタイルを適用するのか考えるのも大事ということで。特急、システム案件ではそのまま使ってみるさらに、UIパーツとグリッドレイアウトでそれぞれ別のCSSフレームワークを併用する、というキメラ案も紹介されていました。私も、機会があればこの方法は採用してみたいです。それから、bootstrapのDL時に機能を限定してDLすることができる、ということも森田さんは紹介されていたので、これも次の案件で試してみたいです。まさあきさんのセッション。Niteの公式情報を引用すると、以下のとおり。“スタティック・サイト・ジェネレータを使って、たった5分で外部から閲覧可能なテストサイトを公開します。”いや、ほんとに10分でやっていました。こもりさんの詳しい動き、何をやっていたかなど、会場で見ていた人の中には、たぶんちんぷんかんぷんだった方も多かったのではないかな、と。Designersでフォローされている、とのこと。Designersそれだけじゃなくて、この次のピクセルグリッドのお三方のセッションで取り上げられていたタスクランナーの導入方法も、こもりさんの本ではカバーされています。その環境構築本が、デザイナー・ディレクターを含めた制作者全員に役立つかというと、そうではないでしょう。Niteは、じつはコーダさんじゃなくてデザイナーさんでも役立つというか、「むしろデザイナーさんにこそ聞いてほしい」というような内容も多かったのですが、こもりさんのセッションに関してはフロントエンド、ド直球といった感じ。少なくとも、自分の肩書が「フロントエンド」の方は、購入されて損はないのかなと感じます。その本を読むことで、10分でゼロからテストサイトまで立ち上げられるかどうかの保証はできかねます。続いては、ここ1年くらいで急激に存在感を増している、ビルドツールの導入方法を丁寧に紹介してくれた、ピクセルグリッドの皆さんのセッション。ビルドツールの難しそうなところは、まず用語がわからないし、小規模の案件だと導入したところであまり高速化できなさそう(な錯覚がある)だし、もし環境構築がうまくいかない場合に誰にも聞けないことも多いし。......と、いろいろハードルがあるわけですが、そんな私のような人にぴったりのセッションだったわけでして、しかもWinでの導入についてもカバーされていたところが素晴らしい。内容については会場参加者(とフォローアップ参加者)の特権ではあるんですけれども、(またまたご紹介です)ピクセルグリッドさんの定期購読で読めるCodeGridの記事の連載として、gulpの導入方法についてがあるそうですので、そちらをぜひ。いうのをまずは知ってほしいところです。できることはいろいろあるそうなんですが、例えば以下のことができるそうです。SASSコンパイルJS圧縮コードの連結CSSスプライトプロジェクトのディレクトリを日付をつけてzipで固めるもうちょっとできることを知りたい場合はこちらを参照。Qiita「できること」を知ってみて、「これはやってみたい!」と思えればしめたもの、って感じで。CLI(コマンドライン)、いわゆる黒い画面のターミナルとかのシェルで操作せずとも導入できるみたいですからね。黒い画面のことも覚えて、gulpも覚えて、sassも覚えて......とかになってしまうと、覚えることとしては供給過多なわけですよ。覚えていけば何かと役に立つんですけれども、まずは小さいところから一歩進めばいいわけです。存さん(発注側)のセッションです。内容は、music.jpさんのリニューアルを受注側として担当されたまぼろしの小林さんと、発注側としてとりまとめた宮地さんのお二人が、どのように改善したか、といった、普段絶対に外に出てこないようなお話。規模の大きいサイトさんですし、それも単にリニューアルというだけでなく、リファクタリング――つまり、CSSやHTMLのコードの中身を改善するプロジェクトに取り組まれたそうです。ある程度の期間サイトが運用されていると、継ぎ足しのコードが増えていくわけです。それは仕方ないことなんでしょうが、それをどうにかできないか、ということで始まったプロジェクトだそうで、KPIは工数削減などを中心に据えたそうです。社内合意は難しかったんじゃないか、というのは想像に難くないですけれども、そこを合意に至り、結果としてかなりの削減に至ったそうです。このプロジェクトでポイントになったは、サイトパーツのコンポーネント化でしょう。最初のセッションの谷さんの内容や、CSSフレームワークを扱ったセッションの森田さんの内容、そしてこの次のセッションの高津戸さんの内容にも出てくる「コンポーネント化」、要は部品化ですけれども、いかにいい意味で「使いまわせる」コンポーネントを作れるかがだいじです。そのためにはデザイナーとの協業が欠かせないわけです。その意味では、デザインとフロントエンドの職域は重なってきていますよね。何度か出てきている、コンポーネント設計についての内容でした。出てきた単語が、粒度。