CSS Nite LP39「Coder's High 2015： コーディングスタイルの理想と現実」のフォローアップページです。
- フォローアップは、五月雨式に追加していきます。
最終更新日： 2015年07月06日 1:21 pm
公開ポリシー
このページは、本イベントの参加者（およびフォローアップ参加者）限定のコンテンツです。 ただし、90日を目安に一般公開する予定です。
- ID/パスワードの情報はツイートなどされないようにお願いします。
ビデオ
ビデオのパスワードは、すべて「CREGPA」です。
- 目的のものと異なる動画が再生される場合には、動画の下のテキストリンクをクリックして、vimeo内でご覧ください。
ツイートは下記にまとめました。公式ツイート担当はふっちーでした。
会場プレゼント
出版社からご提供いただき、会場でプレゼントした書籍などです。当選された方は、ぜひAmazonなどにレビューを投稿いただければ幸いです。
- インプレスから『Web制作者のためのCSS設計の教科書』
- KADOKAWA/アスキー・メディアワークスから『レスポンシブEメールデザイン』、『CSS3&jQueryで作る スマートフォンサイトUI図鑑』
- アップルップルからトートバッグ
- 技術評論社から『改訂版 Webデザイナーのための jQuery入門』
- こもりまさあきさんから『Development Environments for Web Designers』
- ソシムから『HTML5&CSS3デザインブック』、『jQueryレッスンブック jQuery 2.x/1.x対応』
- マイナビから『Webアプリ構築のためのAngularJS』
- ピクセルグリッドからステッカー50部
基調講演：CSS設計の理想と現実
谷 拓樹（サイバーエージェント）
フォローアップはこちらにまとめました。追記することがあります。
LP39-s1-tani from CSS Nite on Vimeo.
理想のCSSフレームワークを探して
森田 霞（アップルップル）
CSS Nite LP39 に参加された皆さま、お疲れさまでした。
セッション3「理想のCSSフレームワークを探して」を担当した森田です。
私よりも経験が多い方々の前でお話するということもあって、物足りないと感じた方もいたかと思いますが、最後まで聞いていただきありがとうございました。
中にはCSSフレームワークを使ったことがなかった方もいたようなので、少しでも今後のCSSフレームワークの使い方の参考になればと思います。
それでは、アンケートにありました質問と会場でしっかり回答できなかった質問への回答です。
- ＞フレームワークの組み合わせは重くなりそうですが、軽くする工夫やそもそも重くならない？
- 使わないパーツが多くなってしまうので、組み合わせないときよりも、もちろん重くなってしまいます。気になる場合は、スライドでもご紹介していた、サイトからカスタマイズしたり、CSSプリプロセッサーからカスタマイズするといった方法を使い、不必要な部分は削除して、必要な部分だけにしてCSSを使うと軽くなります。
- ＞他に面白かったコードはありますか？
- こちらは質疑応答で出た質問です。
Bootstrap や Foundation のpullとpushのグリッドシステムの実装が変わっていて面白かったです。こちらはスライドでもご紹介しましたが、position: relative; を使って、HTMLの順序に依存せずにレイアウトを変更できます。例えば幅が25%のものを右寄せにしたい場合は、left: 75%;と記述することで、左から75%のところから始まるようにして、右に寄せています。
CSS Nite LP39「理想のCSSフレームワークを探して」 from CSS Nite on Vimeo.
5分でゼロからテストサイトまで立ち上げます！
こもり まさあき
「CSS Nite LP39」に参加された皆様、長丁場お疲れ様でした。セッション3のこもりフォローアップです。
5分でテストサイトを立ち上げるデモのみのセッションをおこないました。
ピンマイク＋10分の時間をいただいたこともあったとはいえ、細かな解説はおこなうことはできませんでしたので、以下簡単ですがフォローを。
今回使ったスタティック・サイト・ジェネレータは「Harp（https://harpjs.com/）」です。
こちら、Sass、Less、Jade、EJS、MarkdownにCoffeeScriptと、Harp本体をインストールするだけで動きます。プラグインとかそういった外部のツールをインストールしたり設定する必要はなく、サーバを起動すればすぐサイト制作に入れる優れものです。また、Dropboxを使った「Harp Platform（https://www.harp.io/）」があるので、制作したものをそのままDropboxホスティングすることもできます。
数ページ〜数十ページ程度のサイトであれば、プログラム言語に不慣れな方が多機能化しまくっているCMSでサイトを作るより、Markdownをはじめとしたテキストファイルのインクルードや簡単な条件分岐やJavaScriptを使ってサイトを構築しやすいかもしれません。
当日実際に作成、公開したファイルは下記GitHubのリポジトリにあります。
https://github.com/gaspanik/cssnitelp39
スタティック・サイト・ジェネレータは古くからいろいろな言語で開発・公開されています。Ruby界隈で人気のMiddlemanやJekyllなども同じものです。「StaticGen（https://www.staticgen.com/）」には、GUIのツールも含めさまざまなジェネレータが公開されていますので、こちらご参考まで。
また、Twitterのハッシュタグ（#cssnite_lp39）でいくつかあげていただいてますが、デモ中に利用していたツールなどは以下になります。
今回は静的なサイトをホスティングできるDivshotを使いましたが、アカウントさえ作っておけばコマンドラインからあのようにサーバを起動することが可能です。当日時間の関係で省略しましたが、ファイルを編集して再度アップロードするのもコマンドで一発ですし、開発サーバ・ステージングサーバ・公開サーバと3段階で環境を用意して公開することもできます。
Harpなどはnode.jsで動くので、環境そのものをheroku.comでホスティングすれば、いちいちサイトを書き出してアップしなくても大丈夫です。PaaS系はテストぐらいは無料で試せますし、費用も大量なアクセスを処理する以外は安価で利用できます。以下はherokuでの動作サンプルです（無料モードで動かしているので、アクセスがないと数分でスリープするので初回アクセス時に時間がかかります）。
https://lp39harp.herokuapp.com/
以上、デモ中は時間の関係もあって詳しい手順を順追って説明することができませんでしたので、セッションそのものが何をやっていたか不明な部分も多々あったかと思います。ただ、ああこういう作り方もできるんだ、と気付いて頂けていれば幸いです。
フレームワークやタスクランナーも含め、制作する時間を短くする術は豊富に揃っています。頭を使う、コードを書く、本来時間をかけるべきところにきちんと時間をかけていただければなぁ、とこもりは思っております。ありがとうございました。
こもりまさあき
Development Environments for Web Designers 〜Webサイト制作の時流に乗り遅れないために、覚えておきたい開発環境の作り方
以下は、セッション中に紹介した現在販売している電子書籍「Development Environments for Web Designers 〜Webサイト制作の時流に乗り遅れないために、覚えておきたい開発環境の作り方」が、CSS Nite LP39に参加された皆様（とフォローアップ参加の皆様）向けとして39%引きで購入できるURLです。
コマンドラインの基本からnode.jsやRubyの環境の作り方、さまざまなツールの紹介、タスクランナーのgulpの基本から実際のコードまで幅広く内容を入れておりますので、当日のセッションで興味を持たれた方は内容を抜粋したサンプルをご覧ください。
https://hive.gl/5TtQl （100p超のサンプルPDF）
CSS Nite LP39「5分でゼロからテストサイトまで立ち上げます！」 from CSS Nite on Vimeo.
ビルドツールはじめの一歩（タスクランナー編）
宇野 陽太（ピクセルグリッド）、坂巻 翔大郎（ピクセルグリッド）、小山田 晃浩（ピクセルグリッド
Gruntとgulpについてのセッション、いかがでしたでしょうか？このセッションでお伝えしたかったのは、タスクランナーそのものもありますが、意外とコマンドラインで必要な操作は少ないということもお伝えしたい意図がありました。例えば、gulpのインストールまでに必要なのは、順に
```
node -v
npm install -g gulp
npm install
```
の計39文字です。これから導入したいと考えているかたはぜひ挑戦してみてください。インストール手順は動画にまとめていますので、以下の補足とあわせて参考にしてください。
「CSSNite LP 39 gulpのインストールから起動まで」
画面はMacですが、Windowsの場合はターミナルのかわりにコマンドプロンプトを使います。
テキストによる詳しい説明も用意しています。
- gulp用: https://github.com/cancer/get-started-gulp
- Grunt用: https://github.com/cancer/get-started-grunt
## 補足
セッション中、インストールに関しての説明不足が一部ありました。
### Windowsのかたへ
Nodeのインストーラを使いインストールしたあと、「node -v」と打ち込んでもうまくnode.jsが動かないことがあります。その場合には、以下のページを参考に、調整をしてみてください
https://webdev.jp.net/windows-nodejs-path/
### Macのかたへ
Nodeのインストーラを使いインストールしたあと、「npm install -g gulp」でエラーになってしまうことがあります。この場合、管理者権限でコマンドを実行します。そのためには、コマンドの前に「sudo」（Super User Doの意味）を付けてください。
つまりこのようになります
```
npm install -g gulp
```
ではなく、以下とします。
```
sudo npm install -g gulp
```
(この後パスワードを聞かれます)
## 質問への回答
アンケートのコメント、全て読ませていただきました。貴重な、参考となるご意見ありがとうございます。
いくつかコメントで質問をいただだきましたのでお答えいたします。
### プレビューサーバにGrunt/gulp設定ファイルを同期するメリットは？
小山田：基本的に、GitではSassから吐出されたCSSファイルや、結合後のJSファイルは管理しないようにし、元ファイル（scssや結合前のJS）のみを管理していました。そのため、プレビュー環境でもビルドする必要があり、プレビューサーバにもGruntやgulpを動かしていました。
### Gruntを使っています。gulpに変える必要はありますか？
小山田：ありません。Gruntとgulpはマリオとルイージのような関係で、できることはだいたい同じです。ただし、gulpのほうが後発ということもあり、処理が効率的(並列で処理してくれる)、スマートな書き方、不要な中間ファイルを出さないようにできる、というGruntにはないメリットがすこしあります。
もし余裕があればgulpも試してみるといいでしょう。
### ピクセルグリッドさん的に、Middlemanのことはどう思いますか？
小山田：個人的にはMiddlemanは大きすぎると考えています。Grunt/gulpのような小回りが効きづらいと考えているので必要がなければ使わないと思います。
### Rubyのバージョン管理にも困っています
小山田：僕もそうなんです！主にSassのためかと思います。個人的に、最近は本家Sassではなく、Rubyに依存しない、libsassを使うのがいいかなと思い始めています。grunt-sass, gulp-sassは、libsassのラッパープラグインでRubyなし、node.jsにのみ依存して利用できるので、こうした、依存をできるだけ少なくする手段をとってみるといいと思います。
### 静的ファイルのみを納品している時に、クライアント側で更新される際のルール
坂巻：HTMLに関しては、量産のためのテンプレートでしたので、クライアント側で更新されることはありませんでした。CSS/JSに関しては変更したい場合は依頼をもらって、変更ファイルを渡しました。またJSファイルの中でもクライアント側で編集したいと言われて、結合対象から外したJSファイルがあり、そのファイルがクライアント側で変更された時は、変更後のファイルと何が差分なのかがわかるものををいただきました。（といっても僕はGitを使っているので差分はGitで出せるのですが）
SCSSに関してですが、クライアント側でCSSを調整したいといった要望がある場合は、SCSSから生成したCSSとは別に、クライアント側で自由に書けるCSSを用意しておくのが良いかと考えています。
```html
<!-- SCSSから生成したCSS -->
<link rel="stylesheet" href="/path/to/file.min.css">
<!-- クライアント側で変更をするためのCSS -->
<link rel="stylesheet" href="/path/to/style-client.css">
```
このように、SCSSから生成されたCSSと、クライアント側でそのCSSにないものを追加したり、上書きしたりするためのCSSを読み込むようにします。メリットはSCSSがわからなくても問題がないこと。デメリットはクライアント側で追記されたCSSによってモジュールが壊れたりする可能性があることでしょうか。
### Gruntを使ったプロジェクトではベンダープレフィクスについては含めなかったのでしょうか
坂巻：ベンダープレフィクスはCompassによって付与されています。これもまた開発開始時期の話になり、Autoprefixerのバージョン0.1が登場したのが2013年4月なのですが、ある程度安定したバージョン1.0が出たのは2013年の12月頃でした。その頃はAutoprefixerの知見が無かったため、Compassを使用していました。
### compassはもう過去のものなのですね（；；）
坂巻：いえ、Compassは使用しています。ベンダープレフィクスで使うこともありますが、`background-image`プロパティなどで使える、`image-url()`や、画像の幅を取得できる`image-width()`をよく使っています。[grunt-contrib-compass](https://github.com/gruntjs/grunt-contrib-compass)を使うことで、GruntからCompassを使うことができます。（Gruntとは別に、compassのインストールが必要です）
### プロジェクトのディレクトリ構造をどうしているか知りたいです
坂巻：大規模サイトのリニューアルといっても、古いコンテンツを残しつつ、新しいものも追加される形でした。なので、基本的にはそのプロジェクトのディレクトリ構成と同じように揃えてたり、いろいろ事情があってのディレクトリ構成なので、参考になるかはわからないのですが、以下の様な形です。
```
project
├ .editorconfig
├ .gitignore
├ Gruntfile.js
├ config_siteA.rb
├ config_siteB.rb
├ Gemfile
├ Gruntfile.js
├ package.json
├ README.md
├ htdocs_siteA/
│ ├ _template
│ ├ _styleguide
│ ├ _jsprototype
│ └ common/
│ ├ css/
│ │ ├ style.css
│ │ ├ font/
│ │ │ └ fontawesome-webfont.woff
│ │ └ src/
│ │ ├ style.scss
│ │ └ partial/
│ │ ├ _setting.scss
│ │ ├ _base.scss
│ │ └ _project-header.scss
│ ├ img/
│ │ ├ misc/
│ │ └ project-header/
│ │ └ logo.png
│ ├ include/
│ │ └ project-header.txt
│ └ js/
│ ├ modernizr.custom.js
│ ├ script.min.js
│ ├ lib.js
│ ├ src/
│ │ └ project-header.js
│ └ vendor/
│ └ jquery.js
└ htdocs_siteB/
└ htdocs_siteAとほぼ同様
```
CSS Nite LP39「ビルドツールはじめの一歩（タスクランナー編）」 from CSS Nite on Vimeo.
music.jpのリファクタリング before / after
小林 信次（まぼろし）、宮地 存（エムティーアイ）
「music.jpのリファクタリング before / after」を担当した小林です。
Twitter上で、懇親会で、ページ表示速度の改善により、変わらなかったと紹介した代表的な数値（ページビューなど）にも影響があったのではないか？というご意見をいただきました。
具体的な理由はあかせませんが、もろもろありまして今回のリファクタリングではページ表示速度に大きな変化はありませんでした。
また、リファクタリングにかかった時間を知りたいというご意見がありました。
コーディング自体は1ヶ月もかかっていません（0.8人月くらいです）。
コーダー飲みもよろしくお願いいたします。
CSS Nite LP39「music.jpのリファクタリング before / after」 from CSS Nite on Vimeo.
柔軟なコンポーネント設計のためのCSS
高津戸 壮（ピクセルグリッド）
「柔軟なコンポーネント設計のためのCSS」を担当した高津戸です。
頂いた質問にお答えいたします。
> スライドのツールが知りたいです
Reveal.jsという、HTMLで出来たプレゼンテーション用のフレームワークです。
https://lab.hakim.se/reveal-js/#/
> blockでmarginとpaddingの選択に迷う
あくまで私個人の考えですが、下にはpadding、上にはmarginで余白を取っています。この選択をしている理由は以下です。
# marginの相殺が起こらないようにするため
marginの相殺は便利ですが、ブロック間の余白を取りたい時、不都合があることがあります。
例えば、ただdivのmargin-bottomに10pxを指定した場合、これは後続する要素のmargin-topと相殺されますが、左右にfloatしたdivにmargin-bottomを指定した場合、これは後続する要素のmargin-topと相殺されません。
また、display:tableな要素についてもmarginの相殺が行われません。
これは仕様的に正しい動作ではあり、有効に利用できるケースも多いですが、相殺される場合、相殺されない場合が入り混じると、混乱の原因となってしまいます。
# 最後の要素のmargin-bottomは、背景色を消す
以下の様なケースだと、marginで余白をとった前者は、子要素の最後のmargin-bottom部分にて、背景色を描画しません。
https://codepen.io/takazudo/pen/JoOZvN
これは、heightがautoな要素内の最後の要素の下marginは、代わりに親要素の下marginとして扱われるためです。
https://www.w3.org/TR/CSS21/box.html#collapsing-margins
https://adiary.org/theme_doc/margin
https://kojika17.com/2012/08/margin-of-css.html
そのような理由で、たとえdiv等が増えてしまったとしても、ブロックの終端の下余白を付けたい場合、それをpaddingにて実装しています。
===
> 下余白派ですが、上と下、どちらが調整しやすいでしょうか
私は昔から下余白の方が調節しやすいと考えていますが、その理由は以下のようなものです。
# 上余白パターンだと、初めのブロックの上余白を殺さないといけないから
上余白パターンだと、エリアの初めに配置される要素の上マージンをなんかしらの方法でゼロにしないと、いきなり大きく空いてしまいます。IE6が対応ブラウザとして当たり前のように入っていた時代は、:first-childが使えなかったため、これを殺すのがやや手間でした。
それに対し、下余白であれば、最後に余白ができてしまいますが、大体において、メインエリア等の最後の部分というのは、大きく余白を空けたいケースがほとんどでした。この余白が問題になるケースはほとんど無いように思います。
# 上余白パターンだと、見出しが連続した時にややこしいから
セッションの中でも軽く述べた通り、見出しの上には比較的大きな余白を取りたいというケースが多いと、個人的に考えています。上余白パターンだと、これを簡単に実現できます。その代わりに、大見出し、中見出し、小見出し…といった具合に、見出しが連続すると、見出し間が空き過ぎ、スカスカになってしまいます。これを何とかするには追加クラスを指定して余白をどうにか調節する等の実装方法になるでしょうが、それは複雑な実装であるように感じます。
また、これもセッションの中で軽く触れましたが、見出しの下には、余白をあまり設けないほうが、見出しとそれに相当する内容が紐付けられているようにみえるため、デザインとしてはベターなのではないか？という個人的な考えがあります。この考えを実現するには、下余白でブロック間の余白を表現したほうが自然です。
上記のような理由で、私個人としては、余白を下に取るパターンを採用しています。ただ、これはあくまで私個人のデザイン視点が含まれた考えになるため、ご参考までに。